Key Revocation for Edge Devices

Abstract

Described herein are techniques for remotely performing key revocation on a device that is not capable of communicating outside the device's local network. The techniques involve including a key revocation instruction in a software update instruction sent to the device. The device may verify the software update instruction using one or more keys to determine whether it is safe to run on the device. For example, the device may verify that the software update instruction was sent by a trusted software provider. The device may execute the key revocation instruction included in the software update instruction to disable use of one of the keys and begin using a new key in place of the disabled key.

Description

[Technical Field]

[0001] Related Applications This 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 December 31, 2020, with attorney docket number G0766.70338US00, which is incorporated herein by reference in its entirety.

[0002] The embodiments described herein relate to remote key revocation on devices that are limited to communication within the device's local network. [Background technology]

[0003] A device may use keys 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 it with a new key. A device may perform a key revocation process to disable the use of one key and begin using a new key in place of the disabled key. Summary of the Invention [Means for solving the problem]

[0004] Described herein are techniques for remotely performing key revocation on a device that cannot communicate outside the device's local network. The techniques involve including a key revocation instruction in a software update instruction sent to the device. The device may verify the software update instruction using one or more keys to determine whether it is safe to run on the device. For example, the device may verify that the software update instruction was sent by a trusted software provider. The device may execute the key revocation instruction included in the software update instruction to disable use of one of the keys and begin using a new key in place of the disabled key.

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

[0006] According to some embodiments, a method for key revocation on a device limited to communication within the device's local network is provided. The device stores a first key and a second key. The method includes receiving, using a processor of the device, instructions for updating software installed on the device from a host system within the device's local network, the instructions including instructions for revoking the first key, and executing the instructions, which causes the device to revoke use of the first key and begin using a third key in place of the first key.

[0007] According to some embodiments, a device is provided that forms part of a local network and is limited to communication within the local network, the device comprising: wireless communication circuitry; a memory configured to store a first key and a second key; and a processor configured to: receive, using the wireless communication circuitry, instructions from a host system in the local network for updating software installed on the device, the instructions including instructions for revoking the first key; and execute the instructions, which cause the device to revoke use of the first key and begin using a third key in place of the first key.

[0008] A system for key revocation on a device without a connection to the device, the device having a first key, the system comprising: wireless communication circuitry; and a processor configured to transmit, to a host system within the device's local network, instructions for updating software installed on the device, the instructions, when executed by the device, causing the device to revoke use of the first key on the device and begin using a second key in place of the first key.

[0009] A device limited to communication within a local network of devices, the device comprising: wireless communication circuitry; a memory configured to store a first key; and a processor configured to: receive instructions for updating software installed on the device from a host system in the local network using the wireless communication circuitry, the instructions including instructions for revoking the first key; verify the instructions using the first key; and execute the instructions after verifying the instructions using the key, wherein execution of the instructions causes the device to disable use of the first key and begin using a second key in place of the first key. [Brief explanation of the drawings]

[0010] [Figure 1] 1 illustrates an exemplary system in which some embodiments of the techniques described herein may be implemented. [Figure 2] 1 illustrates an exemplary software architecture of a device in accordance with some embodiments of the techniques described herein. [Figure 3] 1 illustrates an exemplary software update instruction set in accordance with some embodiments of the techniques described herein. [Figure 4A] 1 illustrates a software provider system for placing a first key on a device in accordance with some embodiments of the technology described herein. [Figure 4B] 2B illustrates a system associated with a user of the device of FIG. 2A placing a second key on the device, according to some embodiments of the technology described herein. [Figure 5] 1 illustrates an exemplary process for a device to perform key revocation, according to some embodiments of the technology described herein. [Figure 6] 1 illustrates an exemplary process for verifying a software update instruction in accordance with some embodiments of the technology described herein. [Figure 7] 1 illustrates an exemplary process by which a system can initiate key revocation on a device, according to some embodiments of the technology described herein. [Figure 8] 1 illustrates an exemplary computer system that may be used to implement some embodiments of the techniques described herein. DETAILED DESCRIPTION OF THE INVENTION

[0011] Certain computing devices, sometimes referred to as "edge devices," are unable to communicate outside of a local network and therefore rely on a host system to communicate outside of the local network. For example, an edge device may rely on a host system located proximate to the edge device to communicate with the system over the Internet. Systems without access to the local network ("external systems") or systems without physical access to the edge device are limited to communicating with the edge device through a host system. As an illustrative example, an edge device may be a battery monitoring device sealed within a battery bag. The battery monitoring device may monitor the status of a battery while the battery is installed and in use in a product (e.g., an automobile). While the battery monitoring device is deployed on a product, it may not be able to communicate over the Internet, and therefore the manufacturer's computer system may be limited to communicating with the battery monitoring device (e.g., to retrieve monitoring data) through a host system proximate to the battery monitoring device.

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

[0013] Throughout the life of an edge device, it may be desirable or even necessary to perform key revocation, in which use of a key by the edge device is stopped (“revoked”) and use of a new key is initiated. For example, if a private key stored in a software provider's computer system is compromised, the corresponding key on the device may need to be revoked to protect the device from being susceptible to receiving unauthorized communications from the manufacturer's computer system. For example, an adversarial entity could use the compromised private key to send software to the device and gain unauthorized control of the device. Without revoking the key corresponding to the private key, the device would not be able to detect that software provided by the adversarial entity is being used unauthorizedly. This problem may be further amplified because the edge device may be one of many edge devices, each using a key to verify software on the device. Thus, the key may be stored on a fleet of user devices. Without revoking the key from the fleet of devices, the adversarial entity could gain unauthorized control of all devices in the fleet. As an illustrative example, each of a fleet of vehicle sensors may store a public key corresponding to the private key of the provider of software installed on the sensor and use that key to verify the software when it is loaded before allowing the software to control the sensor. If an adversary were to gain access to the software provider's private key, the adversary could send their own software to the vehicle sensor signed using the private key. Because the vehicle sensor still uses the key corresponding to the private key, the vehicle sensor would load the adversary's software, allowing it to control the sensor.

[0014] The inventors have recognized that remote key revocation on an edge device is difficult due to limitations in communication with the edge device. A system (e.g., a software provider system) that needs to initiate key revocation cannot directly communicate with the edge device to do so. Instead, key revocation on an edge device is initiated by an intermediate host system that can communicate with the edge device (e.g., over a local network). However, an edge device that receives a key revocation command 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 over the Internet to verify that the key revocation request was generated by a trusted software provider system. The edge device would be unaware if the host system that sent the request was compromised or if the key revocation request received from the host system was initiated by a hostile entity. Conventional techniques do not allow secure remote key revocation on an edge device without a third-party verification authority.

[0015] The inventors have developed a technique for securely performing remote key revocation on an edge device without the need for a third-party verification authority. The technique provides a remote key revocation process that does not rely on a host system to initiate the remote key revocation. This prevents a compromised host system, or a compromised system communicating with a host system, from performing unauthorized key revocation on the edge device. The technique leverages a secure software update process to perform the key revocation.

[0016] Some embodiments of the techniques described herein use a secure software update procedure to perform key revocation on a device that is limited to communications within the device's local network. The technique embeds software instructions for performing key revocation within software update instructions provided to the device. When the device receives the software update instruction, the device may verify and execute the software instructions, resulting in the revocation of the key and the initiation of a new key in place of the revoked key. The technique limits initiation of key revocation on an edge device to the secure software update procedure used to update software on the edge device and therefore does not allow a host system to initiate key revocation. In some embodiments, the device's local network lacks a third-party verification authority that the device can use to verify instructions received by the device. Thus, the device may not be able to communicate with any such third-party verification authority. By embedding the key revocation instruction within the software update instruction, some embodiments eliminate the need for the device to participate in communications (e.g., in a challenge-response protocol) to request key revocation. This eliminates the opportunity for an adversary to intercept a request to perform key revocation sent by the device and thereby provide their own new key to use in place of the revoked key. Instead, the device uses one or more of its keys to verify software update instructions provided to the device, and key revocation occurs if the software update instructions are verified, otherwise it is not performed.

[0017] Some embodiments of the technology described herein perform remote key revocation using a trusted software platform on an edge device. The trusted software platform may enable the device to perform key revocation even if the device's keys have been compromised. The device's trusted software platform verifies software loaded on the device using two keys, each provided by a separate party. The trusted software platform includes multiple software layers that are loaded sequentially. The software layers may include one or more trusted boot loaders that verify the software using the two keys before allowing the software to operate the device.

[0018] Thus, the techniques described herein improve the security of edge devices by enabling key revocation to occur in a secure manner. Due to the edge device's inability to communicate with a third-party verification authority, conventional techniques either require the edge device to execute a revocation command without verifying that the command was sent by a trusted source (e.g., the device manufacturer and / or the provider of software installed on the device), or otherwise do not include key revocation functionality in the edge device, making the edge device susceptible to an adversary gaining access to a key corresponding to the device's key (e.g., an adversary obtaining a private key corresponding to a public key stored on the device). The techniques described herein provide a more secure edge device that includes a key revocation function for protection against communications from compromised external systems and the ability to verify that a key revocation command is from a trusted source.

[0019] Some embodiments may allow for one-time revocation, in which case the edge device stores a flag indicating whether a key has been revoked. Some embodiments may allow for a predetermined number of key revocations, in which case the edge device selects from a set of keys during each revocation. Some embodiments may allow for an unlimited number of revocations, in which case each revocation updates the key. Some embodiments of the technology described herein include a key selection mechanism that indicates to the edge device to stop using one key and start using another key. A secure key mechanism may use a flag indicating that a key has been revoked and an indication of the new key.

[0020] 1 illustrates an example system 100 in which some embodiments of the techniques described herein may be implemented. The system 100 includes a device 102 and a host system 104 in a local network 110, and a software provider system 106 that communicates with the host system 104 through a network 108. The device 102 is an edge device. As illustrated in FIG. 1, the device 102 is limited to communicating with devices within the device's local network 110. The device 102 cannot communicate with the software provider system 106 through the network 108 or otherwise directly with the software provider system 106.

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

[0022] 1, the device 102 includes a processor 102A, a wireless communication circuit 102B, and a memory 102C. In some embodiments, the device 102 may include a system-on-chip (SoC) that includes the processor 102A, the wireless communication circuit 102B, and the memory 102C.

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

[0024] The processor 102A may be configured to perform key revocation. The processor 102A may perform the revocation by executing software instructions stored on the device 102 (e.g., in memory 102C). The processor 102A may be configured to perform the key revocation by receiving instructions for updating software installed on the device 110 from a host system 104 in the device's local network 110. The instructions for updating software installed on the device 110 may include software instructions for updating the 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 key revocation (e.g., stored in memory 102C). When the processor 102A executes the key revocation instructions, they cause the device 102 to revocation the use of one key and begin using another key in place of the revoked key. In some embodiments, the revocation instruction, when executed by the processor 102A, may cause the processor 102A to access a new key from the memory 102C of the device 102 and configure the device 102 to use the new key in subsequent operations instead of the first key. For example, the revocation instruction may cause the processor 102A to access the new key from a flash memory of the device 102. In some embodiments, the revocation instruction may include the new key. In such embodiments, the processor 102A may copy the new key from the revocation instruction into its memory 102C and use the new key in subsequent operations instead of the first key.

[0025] As an illustrative example, device 102 may be a vehicle controller device having software installed thereon for electronically controlling a vehicle (e.g., the vehicle's climate system control, cruise control, autonomous driving, braking, and / or another aspect). Host system 104 may be the vehicle's central electronic control unit (ECU) through which device 102 receives software updates. In this example, the vehicle controller device may receive an update to its control software that also includes key revocation instructions. For example, the vehicle controller device may receive the update including the key revocation instructions due to a breach of software provider system 106 in which an adversary gained access to a private key corresponding to device 102's previous key. Thus, the adversary could be able to send its own software instructions to device 102 signed with the private key. Because the vehicle controller device does not have access to a third-party verification authority (e.g., over the Internet), the vehicle controller device would not be able to determine that the software instructions were sent by an adversary.

[0026] Returning again to FIG. 1 , the wireless communication circuit 102B may comprise a transceiver that enables the device 102 to communicate with one or more external systems (e.g., the host system 104) within a range of the device 102. For example, the transceiver may be a BLUETOOTH transceiver, an infrared (IR) transceiver, a radio transceiver, or any other suitable type of transceiver. The wireless communication circuit 102B may be configured to communicate within the device 102's local network (e.g., network 110). The device 102 may use the wireless communication circuit 102B to transmit and / or receive data from external systems. For example, the device 102 may use the wireless communication circuit 102B to transmit and / or receive data in packets. In some embodiments, the wireless communication circuit 102B may be limited to communication within the device 102's local network 110. The local network 110 may have a boundary that is within a proximity of the wireless communication circuit 102B. For example, the wireless communication circuit 102B may be limited to communicating with external systems within a threshold distance of the wireless communication circuit 102B. The threshold distance may be 10 feet, 20 feet, 30 feet, 40 feet, 50 feet, 100 feet, 200 feet, or other suitable distance from wireless communication circuit 102B. In some embodiments, local network 110 may be a wireless local network (WLAN), e.g., a WLAN may include a router configured to transmit and receive data over radio frequencies. In some embodiments, local network 110 may be a communications network between wireless communication circuit 102B and one or more external systems.

[0027] The memory 102C may comprise hardware that can be configured to store information. For example, the memory 102C may comprise an integrated circuit used to store information. The memory 102C 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 102C may include volatile memory such as static random access memory (SRAM) and / or dynamic random access memory (DRAM).

[0028] As shown in FIG. 1 , memory 102C is configured to store one or more keys. A key may be a cryptographic key used to perform cryptographic operations, including authenticating data, encrypting data, decrypting data, generating and / or verifying signatures, verifying software instructions, and / or other cryptographic operations. In some embodiments, a key may consist of a character set. For example, a key may be a randomly generated string. In some embodiments, a key may be generated using a key generation algorithm. For example, a key may be generated using a deterministic random number 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, a 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, a key may include an asymmetric key. An asymmetric key stored in memory 102C may be a public key corresponding to a private key. In some embodiments, a key may include a symmetric key. The symmetric key stored in memory 102C may be the same as a key stored in another system.

[0029] In some embodiments, the key 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 the software provider system 106, and a second key may be generated by a system associated with a user of the device 102. A system associated with a user of the device 102 may also be referred to herein as a “user system.” To illustrate, the software provider system 106 may be associated with a device manufacturer. When the device 102 is with the manufacturer, the manufacturer may use the software provider system 106 to generate a key (e.g., a symmetric key or a public key) that is then stored in memory 102C. A user of the device 102 (e.g., an entity purchasing the device 102) may use the user system to generate a key (e.g., a symmetric key or a public key) that is then stored in memory 102C.

[0030] In some embodiments, the key may include a single key generated by an external system. In some embodiments, the key may be generated by the software provider system 106. For example, the software provider system 106 may generate the key while the device 102 is with the manufacturer and store the key in memory 102C. In some embodiments, the key may be generated by a user system. For example, the key may be generated by the user system and stored in memory 102C of the device 102 prior to deployment of the device 102.

[0031] In some embodiments, the keys may include one or more keys for use after revocation. A key used after revocation may be referred to herein as a “revocation key.” For example, the keys 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 using the first key and begin using the revocation key to perform cryptographic operations. In some embodiments, the keys may include multiple revocation keys. In such embodiments, each time the device 102 performs a revocation, the device 102 may revocation the previous key and begin using one of the multiple revocation keys. For example, the keys may include two, three, four, five, or more revocation keys. In some embodiments, the keys may include a single revocation key. In such embodiments, the device 102 may be limited to performing one revocation. In some embodiments, the revocation key may be stored in memory 102C for use prior to deployment of the device 102. For example, the revocation key may be stored in memory 102C during manufacture of the device 102. In another example, a revocation key may be stored in memory 102C by a device user prior to deploying device 102 for use. In some embodiments, the amount of storage space in memory 102C may limit the number of keys that can be stored therein. For example, the amount of storage space in memory 102C may limit the number of keys to two, three, four, or five keys.

[0032] 2 illustrates an exemplary software architecture 200 of device 102 in accordance with some embodiments of the techniques described herein. As illustrated in FIG. 2, software architecture 200 includes first boot loader 202, second boot loader 204, operational software 206, communication software 208, and over-the-air (OTA) processing software 214. In some embodiments, first boot loader 202 may be an immutable hardware boot loader (e.g., in ROM), and second boot loader 204 may be an optional subsequent boot loader that performs additional verification. In some embodiments, second boot loader 204 may be stored in flash memory.

[0033] The device 102 may be configured to use a first boot loader 202 and a second boot loader 204 when loading operational software 206 onto the device 102. Each of the boot loaders 202, 204 may include a set of instructions stored in the memory 102C of the device 102 that are executed to load the operational software 206 into the memory of the device 102. For example, the first boot loader 202 may be stored in read-only memory (ROM) and the second boot loader 204 may be stored in flash memory. The device 102 may be configured to sequentially load the operational software 206 in stages using the boot loaders 202, 204. In some embodiments, each of the boot loaders 202, 204 may be configured to verify the operational software 206 using its own key. For example, the first boot loader 202 may verify a first signature of the operational software 206 using a first key, and the second boot loader 204 may verify a second signature of the operational software 206 using a second key. The first signature may be generated by a software provider system, and the second signature may be generated by a user system. In embodiments in which the first boot loader 202 and the second boot loader 204 are each configured to verify the operational software 206 using their own respective keys, for an adversary to load the operational software onto the device 102, the adversary would need to send the device 102 software containing two separate signatures generated using two separate keys from two different parties (e.g., the software provider and the user).

[0034] As shown in FIG. 2 , the operational software 206 may use communications software 208 to operate the device's wireless communication circuitry 210. The wireless communication circuitry 210 may be the wireless communication circuitry 102B described herein with reference to FIG. 1 . The communications software 208 may enable the device 102 to transmit and receive data from the host system 104. The communications software 208 may be configured to receive software update instructions 212 from the host system 104 using the wireless communication circuitry 210. The software update instructions may include key revocation instructions. As shown in FIG. 2 , software update instruction processing 214 is performed by the second boot loader 204. Because the software update may include updating the boot loaders 202, 204, the software update instruction processing 214 is performed by the second boot loader. In some embodiments, the operational software 206 may be restricted from modifying the boot loaders 202, 204. Restricting the operational software 206 from modifying the boot loaders 202, 204 may ensure that the boot loaders 202, 204 are protected from any adversary and therefore can be trusted to update software on the device 102. In such an embodiment, software updates may not be performed by the operational software 206.

[0035] While the exemplary embodiment of FIG. 2 includes two boot loaders, in some embodiments, the software architecture of the device may include a single boot loader. That boot loader may be configured to perform the operations of boot loaders 202, 204 described herein. In some embodiments, the boot loader may be an immutable hardware boot loader. For example, the immutable hardware boot loader may be a ROM boot loader. In some embodiments, the software architecture may include one or more subsequent optional boot loaders that may be configured to perform additional verification. In such embodiments, the optional boot loader may not be required to load operational software onto the device or to verify software instructions (including, for example, key revocation instructions).

[0036] The host system 104 may comprise one or more computing devices within the local network 110. The host system 104 may be located within the vicinity of the device 102, where the device 102 can communicate with the host system (e.g., using wireless communication circuitry 102B). The host system 104 may be configured to communicate over a network 108 outside of the device's local network 110. As shown in FIG. 1, the host system 104 may communicate with the software provider system 106 over the network 108. For example, the host system 104 may include wireless communication circuitry that enables the host system 104 to communicate over the Internet. As an illustrative example, the host system 104 may be a central electronic control unit (ECU) of a vehicle, while the device 102 may be a vehicle controller device for a particular component of the vehicle (e.g., climate control, cruise control, autonomous driving, and / or braking).

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

[0038] The software provider system 106 may be configured to remotely perform key revocation on the device 102. The software provider system 106 may be configured to remotely revoke a key on the device 102 by generating software update instructions that include the key revocation instructions. The software provider system 106 may transmit the software update instructions over the network 108 to the host system 104 for transmission to the device 102. In some embodiments, the software provider system 106 may be configured to (1) generate software update instructions to include an update to software installed on the device 102 and the key revocation instructions, and (2) 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 a cryptographic hash of the software update instructions encrypted by the software provider system 106. The software update installed on the device 102 may be a software image, and the key revocation instructions may include software instructions that, when executed by a processor of the device 102, cause the device to stop using a key and begin using a new key for cryptographic operations in place of the revoked key. The software update instruction may be verified using a key currently being used by the device 102 to verify information and instructions sent by the software provider system 106. For example, the software provider system 106 may digitally sign the software update instruction using a private key that corresponds to a public key stored by the device 102. In another embodiment, the software provider system 106 may digitally sign the software update instruction using a symmetric key that is also stored by the device 102.In some embodiments, the software provider system 106 may be configured to sign the software update using a new key (e.g., a new private key) so that the device 102 can verify the software update using a corresponding new key (e.g., a new public key) used as a result of executing the revocation instruction. The device 102 may be configured to verify the updated software using the new key (e.g., when the software is loaded onto the device 102).

[0039] 3 illustrates an exemplary software update instruction set 300, in accordance with some embodiments of the techniques described herein. The software update instructions 300 may be generated by the software provider system 106 of FIG.

[0040] The software update instructions 300 include a set of key revocation instructions 302. The key revocation instructions 302 may be executable by a processor of the device 102. When executed, the key revocation instructions 302 may cause the device 102 to stop using a first key for cryptographic operations and to begin using a new key for subsequent cryptographic operations. For example, the key revocation instructions 302 may cause the processor to update a flag associated with the first key stored in memory indicating that the first key is no longer in use and / or update a flag associated with a new key in memory indicating that the new key is to be used. In another example, the key revocation instructions 302 may cause the device 102 to remove the first key from the device's memory 102C. In another example, the key revocation instructions 302 may identify a location in the device's memory 102 that stores a new key from which the device 102 obtains the key for use in cryptographic operations. In another embodiment, the revocation instructions 302 may change a variable in the memory 102C of the device 102 that causes the device 102 to use a new key instead of the first key. The software update instructions 300 include a software image 304. The software image 304 may be an updated software image of software installed on the device. For example, the software image 304 may update operations performed by the device 102, fix bugs in the software of the device 102, or otherwise modify the software of the device 102.

[0041] The software update instruction 300 of FIG. 3 is signed with two signatures: a first signature 300A generated by the software provider system 106 using a first key, and a second signature 300B generated by the user system using a second key. The device 102 may be configured to verify the software update instruction 300 using both signatures (e.g., as performed in process 600 described herein with reference to FIG. 6). In this embodiment, for an adversary to be able to send a software image and / or key revocation instruction to the device 102, the adversary would need access to both the first key and the second key to generate the two signatures. As indicated by the dotted line around the signature 300B generated using the second key, in some embodiments, the software update instruction 300 may be signed with only the signature 300A generated using the first key. In such embodiments, the software update instruction 300 may be signed by the software provider system 106 but not by the user system.

[0042] As shown in FIG. 3 , the software image 302 is signed with a signature 304A generated using a new key to be used after the device 102 executes the key revocation instruction 302. The device 102 may verify the new software image 304 using the new key. For example, the device 102 may verify the new software image 304 using the new key when loading the software after power-on. The software image 304 is also signed with a signature 304B generated using a second key (e.g., of the user system). The device 102 may verify the software image 304 using signature 304B in addition to signature 304A generated using the new key. In some cases, the new software image 304 may be functionally identical to the software image currently on the device. In such cases, the new software image 304 may be provided to provide a new key and / or signature 304B. Thus, the software update instruction 300 may be used to perform key revocation without updating the software's functionality.

[0043] As indicated by the dotted line in signature 304B, in some embodiments, software image 304 may be signed with signature 304A without signature 304B. For example, a user system may not sign software image 304. In another example, a user system may sign software update instructions 300, but a software provider system may not. In some embodiments, software update instructions 100 are signed by one entity (e.g., a software provider system or a user system) and distributed (e.g., to a host system) by another entity (e.g., a user system or a software provider system) that does not sign software update instructions 100. For example, a software provider system may sign software instructions 300, and a user system may distribute software update instructions 300 to a host system. In such an embodiment, an adversary would still need access to two separate systems (i.e., a signing system and a distribution system) to gain access to be able to provide key revocation instructions to a device.

[0044] 4A illustrates a software provider system 400 that places a first key on a device 410 in accordance with some embodiments of the techniques described herein. In some embodiments, the software provider system 400 may be the software provider 106 of FIG. 1 and the device 410 may be the device 102 of FIG. 1.

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

[0046] The software provider system 400 transmits the public key 402B and the signature to the device 410. As shown in FIG. 4A , the software provider system 400 transmits the public key 402B and / or the signature to the device 410 for storage in the memory 440 of the device 410. In some embodiments, the software provider system 400 may transmit the public key 402B to the device 410 through a physical connection. For example, the software provider system 400 may connect to the device 410 using a Joint Test Action Group (JTAG) connection, a Serial Peripheral Interface (SPI), an I2C connection, a low pin 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 400 may transmit the public key 402B to the device 410 through a wireless connection. For example, the software provider system 400 may connect to the device 410 using a Bluetooth, infrared, Wi-Fi, or other suitable wireless connection. In some embodiments, the software provider system 400 may be configured to send the public key 402B to the device 410 during manufacturing. The software provider system 400 may be associated with the manufacturer of the device 410. Before shipping the device 410 to a user, the software provider system 400 may send the public key 402B to the device 410.

[0047] As shown in FIG. 4A , the software provider system 400 further performs signature generation 408 using a private key 402A to generate a signature. The software provider system 400 sends the generated signature to the device 410 for storage in memory 440. A public key 402B corresponding to the private key 402A used to generate the signature can then be used by a user system to verify that the signature loaded into the memory 440 of the device 410 is a valid signature of the software provider. In some embodiments, the software provider system 400 can be configured to generate the signature by encrypting data using the private key 402A to obtain encrypted data. The public key 402B stored in the memory 440 of the device 410 can be used by the user system to verify that the signature stored in the device 410 is valid (e.g., using RSA, ECDSA, or other suitable digital signature scheme).

[0048] 4A, software provider system 400 generates a private / public key pair, in some embodiments, software provider system 400 may be configured to generate symmetric keys. In such embodiments, system 400 may generate a single key that is sent to device 410 for storage in memory 440. Software provider system 400 may use the same key to encrypt a message authentication tag. The user system may use the key to verify that the message authentication tag has not been altered.

[0049] FIG. 4B illustrates a user system 430 associated with a user of device 410 of FIG. 2A that places a second key on device 410, in accordance with some embodiments of the techniques described herein. In the example of FIG. 4B, user system 430 performs private / public key pair generation 432, in which user system 430 generates a key pair consisting of private key 432A and corresponding public key 432B. Private key 432A may not be shared outside user system 430, while corresponding public key 432B may be distributed outside user system 430. In some embodiments, user system 430 may be configured to perform key generation 432 to obtain an asymmetric key pair for a signature algorithm. Exemplary algorithms are described herein with reference to FIG. 4A. In some embodiments, user system 430 may be configured to perform key generation 432 to generate a symmetric key.

[0050] 4A , the user system 430 transmits the public key 432B to the device 410 for storage in the memory 440 of the device 410. In some embodiments, the user system 430 may be configured to transmit the public key 402B to the device 410 through a physical connection. For example, the user system 430 may transmit the public key 432B to the device 410 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 430 may be configured to transmit the public key 402B to the device 410 through a wireless connection. For example, the user system 430 may transmit the public key 432B to the device 410 using a BLUETOOTH connection, an infrared connection, a Wi-Fi connection, or other suitable wireless connection. In some embodiments, the user system 430 may be configured to transmit the public key 432B to the device 410 prior to deployment. For example, the device 410 may be obtained from a manufacturer. The user system 430 may transmit the public key 432B to the device 410 after the device 410 is obtained from the manufacturer. The user system 430 may be further configured to verify the publication of the software provider system stored in the memory 440 of the device 410, as described herein with reference to FIG. 4A.

[0051] 4B, user system 430 generates a private / public key pair, but in some embodiments, user system 430 may be configured to generate symmetric keys. In such embodiments, system 430 may be configured to generate a single key that is sent to device 410 for storage in memory 440.

[0052] 5 shows an example process 500 for a device to perform key revocation in accordance with some embodiments of the techniques described herein. Process 500 may be performed by device 102 described herein with reference to FIG. 2. In some embodiments, process 500 may enable a device to perform key revocation without having to request key revocation from another system. For example, process 500 may be performed without the device communicating a request to the system to perform key revocation.

[0053] Process 500 begins at block 502, where a device receives instructions from a host system (e.g., host system 104 described herein with reference to FIG. 1) to update software installed on the device. An exemplary instruction set is described herein with reference to FIG. 3. The instructions may be provided to the host system from a software provider system (e.g., software provider system 106). The device may be configured to receive instructions to update software through a connection with the host system within the device's local network. In some embodiments, the device may receive instructions to update 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 the vehicle's ECU connected to the device through a wired connection. In some embodiments, the device may receive instructions to update software installed on the device through a wireless connection. For example, the device may be able to wirelessly communicate with the host system within the device's local network.

[0054] Process 500 then proceeds to block 504, where the device uses one or more keys to verify the instructions received in block 502. The device may be configured to use the key to verify that the instructions were received from a trusted source. For example, the device may use the key to verify that the instructions were generated by a software provider system (e.g., the device's manufacturer). In some embodiments, the device may be configured to verify the instructions using the key. 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 use the key to verify a message authentication tag (e.g., if the key is a symmetric key).

[0055] In some embodiments, a device may be configured to verify instructions using multiple keys. The multiple keys may be stored on the device for use prior to deploying the device. For example, the device may verify 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 be stored on the device as described herein with reference to FIGS. 4A and 4B. Process 600 represents an example process a device may perform to verify instructions using multiple keys.

[0056] Next, process 500 proceeds to block 506, 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 a boot loader of the device. For example, the device may execute the instructions using a boot loader, as described with reference to reference numeral 214 of FIG. 2.

[0057] Next, process 500 proceeds to block 508, where the device disables use of the first key and begins using a new key in place of the first key. The device may perform the step of block 508 as a result of executing the instructions at block 506. The instructions cause the device to perform the disablement. In some embodiments, the device may set a flag that causes the device to disable use of the first key and begin using a new key stored in the device's memory. For example, the flag may invoke a software function that, when executed, causes the device to disable use of the first key and begin using the new key. In some embodiments, the instructions may include a 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 change a flag associated with the first key to indicate that the first key will no longer 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 multiple keys stored in the device's memory. The updated index may indicate a new key instead of the first key. For example, the device may update the index by incrementing it. In another example, the device may update the index by randomly setting it to a value different from its current value.

[0058] In some embodiments, the device may disable 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 hash of a data set used to verify a digital signature. For example, the device may compare a decryption of a digital signature obtained using the first key with the data (e.g., a hash of the data set) to verify the digital signature. The device may disable use of the data associated with the first key and begin using new data associated with a new key. The device may replace the data associated with the first key with 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.

[0059] 6 shows an example process 600 for verifying a software update instruction in accordance with some embodiments of the techniques described herein. Process 600 may be performed by device 102 described herein with reference to FIG. 1. In some embodiments, process 600 may be performed as part of block 508 of process 500 described herein with reference to FIG. 5. In some embodiments, process 600 may also be performed by the device at every boot to verify installed software before loading the software.

[0060] A device performing process 600 may be configured with a multi-boot loader software architecture (e.g., as described herein with reference to FIG. 2). The device may have a first boot loader and a second boot loader. The first and second boot loaders may also be referred to herein as a primary boot loader and a secondary boot loader, respectively. Each of the boot loaders may be configured to use a respective key when performing the verification. The first boot loader may be configured to use a first key (e.g., a key provided by a software provider), and the second boot loader 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 boot loaders may be configured to use both the first and second keys. The software instructions may be encrypted using two keys corresponding to the first and second keys. In some embodiments, the instructions may be digitally signed using the 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. The software provider system may sign the instructions using a first private key, and the user system may sign the instructions using a second private key.

[0061] Process 600 begins at block 602, where a device verifies instructions using a first key using a first boot loader. The device may load the first boot loader from the device's memory (e.g., ROM or flash). The first boot loader may be configured to verify the instructions using a first key (e.g., a first public key or a first symmetric key). The first boot loader may be configured to verify a first digital signature included in the instructions using the first key. In this example, the first boot loader may verify the first digital signature using the key by (1) decrypting the encrypted data of the first digital signature using the first key to obtain a decrypted body of the encrypted data, and (2) verifying the first digital signature based on the decrypted body. The first boot loader may verify the first digital signature based on the decrypted body by determining whether the decrypted body matches an expected output of the decryption. For example, the encrypted data may be an encrypted body of a hash of a data set. In this embodiment, the first boot loader may verify the digital signature by determining whether a decrypted body of the encrypted data matches a hash of the data set. If the decrypted body matches the hash of the data set, then the first boot loader may determine that the first digital signature is valid. If the decrypted body does not match the hash of the data set, then the first boot loader may determine that the first digital signature is invalid.

[0062] Next, process 600 proceeds to block 604, where the device determines whether the instructions were verified at block 602. If verification of the instructions at block 602 fails, then process 600 proceeds to block 612, where the device prevents execution of the instructions. At block 612, 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 the previous version of the software and continue to use the current key for verification.

[0063] If the device verifies the instructions at block 602 (e.g., by determining that the first digital signature is valid), then process 600 proceeds to block 606, where the device verifies the instructions using a second key using a second boot loader. The device may load the second boot loader from the device's memory (e.g., ROM or Flash). The second boot loader may be configured to verify the instructions using a second key (e.g., a second public key or a second symmetric key). The second boot loader may be configured to verify a second digital signature included in the instructions using the second key. In this example, the second boot loader may verify the second digital signature using the key by (1) decrypting the encrypted data of the second digital signature using the second key to obtain a decrypted body of the encrypted data, and (2) verifying the second digital signature based on the decrypted body. The second boot loader may verify the second digital signature based on the decrypted body by determining whether the decrypted body matches an expected output of the decrypted body. For example, the encrypted data may be an encrypted version of a hash of the data set. In this embodiment, the second boot loader may verify the digital signature by determining whether the decrypted version of the encrypted data matches the hash of the data set. If the decrypted version matches the hash of the data set, then the second boot loader may determine that the second digital signature is valid. If the decrypted version does not match the hash of the data set, then the second boot loader may determine that the second digital signature is invalid.

[0064] Process 600 then proceeds to block 608, where the device determines whether the instruction was verified at block 606. If the instruction verification at block 606 fails, then process 600 proceeds to block 612, where the device prevents execution of the instruction as described above. If the instruction was verified at block 606, then process 600 proceeds to block 610, where the device allows execution of the instruction. For example, the instruction may be executed by a second boot loader or by the device's operating software. The instruction may be executed as described at blocks 506 and 508 of process 500 described herein with reference to FIG. 5.

[0065] 7 shows an example process 700 for a system to perform key revocation on a device, according to some embodiments of the techniques described herein. In some embodiments, process 700 may be performed by software provider system 106 to revoke a key on device 102 as described herein with reference to FIG.

[0066] Process 700 begins at block 702, where the system obtains a key revocation instruction that, when executed by a device, may cause the device to disable use of a first key and replace it with a new key, as described in blocks 506-508 of process 500 described herein with reference to FIG. 5. For example, the system may generate a file containing code that encodes the key revocation instruction.

[0067] Next, process 700 proceeds to block 704, 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 be generated by compiling source code on another system and then transmitted to the system performing process 700.

[0068] Next, process 700 proceeds to block 706, where the system digitally signs the software update using a new key. The new key may correspond to a new key to be used by the device in place of the first key after revocation has occurred. In some embodiments, the new key may be a new private key corresponding to a new public key used on the device. In some embodiments, the new key may be a new symmetric key also used on the device. The system may be configured to digitally sign the software update by generating a digital signature to be included in the software update. The system may be configured to generate the digital signature by (1) obtaining a set of data and (2) encrypting the data set using the new key to obtain the encrypted data set as a digital signature. In some embodiments, the system may be configured to obtain the data set by hashing data (e.g., text data) to obtain the data set. The system may encrypt the hashed data set using the new key. By digitally signing the software update using the new key, the software update may be verified by the device after execution of the revocation instruction using the device's corresponding new key.

[0069] Process 700 then proceeds to block 708, 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 that include the software update and the revocation instructions. For example, the system may generate a file that includes the software update (e.g., a software image) and a file that includes the revocation instructions. The system may store the two files as software update instructions within a single data package. An exemplary software update instruction set that may be generated by the system is described herein with reference to FIG. 3.

[0070] Next, process 700 proceeds to block 710, where the system digitally signs the software update instruction using a first key corresponding to the key the device is currently configured to use for verification. The system may digitally sign the software update instruction by generating a digital signature that is included with the software update instruction. Techniques for generating a digital signature using a key are described herein. The device may be configured to verify the software update instruction using a key corresponding to the first key. For example, the device may verify the software update instruction using a public key corresponding to the first key. In another embodiment, the first key may be a symmetric key, and the device may verify the software update instruction using the first symmetric key.

[0071] Next, process 700 proceeds to block 712, where the system transmits the software update instruction. In some embodiments, the system may be configured to transmit the software update instruction to a user system. The user system may digitally sign the software update instruction. In some embodiments, the user system may verify the digital signature of the system performing process 700, and if the user system determines that the digital signature is valid, the user system may digitally sign the software update instruction by generating its own digital signature. The user system may then transmit the software update instruction to a host system (e.g., host system 104) for transmission to the device. In some embodiments, the user system may transmit the software update instruction to the host system without digitally signing the software update instruction. In such embodiments, the software update instruction may be signed by a single entity (e.g., the system performing process 700). The device may verify the software update instruction by verifying both digital signatures included in the software update instruction. In some embodiments, the system performing process 700 may be configured to transmit the software update instructions to the host system without transmitting them to the user system. The device may verify the software update instruction by verifying the system's digital signature included in the software update instruction. Sending the software update instruction to the device may cause the device to perform process 500 described herein with reference to Figure 5. The device may revoke use of the key and begin using another key in place of the revoked key.

[0072] In some embodiments, the system may be configured to transmit software update instructions, including key revocation instructions, without receiving any request generated by the device. For example, the system may transmit software update instructions without participating in any communication protocol with the device. As described herein with reference to FIG. 4, the device may receive instructions (e.g., through a host system) without requesting the instructions. This may eliminate the opportunity for an adversary to intercept such requests and / or transmit their own keys to the device.

[0073] 8 shows a block diagram of an exemplary computer system 800 that may be used to implement embodiments of the techniques described herein. The computing device 800 may include one or more computer hardware processors 802 and non-transitory computer-readable storage media (e.g., memory 804 and one or more non-volatile storage devices 806). The processor 802 may control the writing and reading of data to and from (1) the memory 804 and (2) the non-volatile storage device 806. To perform any of the functions described herein, the processor 802 may execute one or more processor-executable instructions stored in one or more non-transitory computer-readable storage media (e.g., memory 804), which may act as non-transitory computer-readable storage media that store processor-executable instructions for execution by the processor 802.

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

[0075] Processor-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 program modules may be combined or distributed. [Explanation of symbols]

[0076] 100 systems 102 devices 102A Processor 102B Wireless communication circuit 102C Memory 104 Host System 106 Software Provider System 108 Network 110 Local Network 200 Software Architecture 202 First Boot Loader 204 Secondary Boot Loader 206 Operating Software 208 Communication Software 210 Wireless communication circuit 212 Software Update Instructions 214 Software update command processing 300 Software Update Instruction Set 300A First Signature 300B Second Signature 300 software instructions 302 Key Revocation Instruction Set 304 Software Images 304A Signature 400 Software Provider Systems 402 Key generation 402A private key 402B Public Key 408 Signature generation 410 devices 430 User System 432 Private / Public Key Pair Generation 432A Private key 432B public key 440 memory 500 processes 600 processes 700 processes 800 Computer Systems 802 Computer Hardware Processor 804 memory 806 Non-volatile storage devices

Claims

1. A method for performing key revocation on an edge device, the method comprising: generating, by a processor, a first software provider signature using a first software provider key corresponding to a first device key stored on the edge device; generating, by the processor, a second software provider signature using a second software provider key corresponding to a third device key to be used in place of the first device key after revocation; transmitting, by the processor, instructions to a host system within a local network of the edge device without connection to the edge device, to update software installed on the edge device, the instructions to update the software comprising: instructions to revoke the first device key and begin using the third device key in place of the first device key; a software image, the instructions to update the software are signed with both the first software provider signature generated by a software provider system and a user signature generated by a user system separate from the software provider system using a user key corresponding to a second device key stored in the edge device; the software image is signed with the second software provider signature; Sending a command; receiving, by the host system, the instructions from the processor; sending, by the host system, the command to the edge device; receiving, by the edge device, the instruction from the host system; performing, by the edge device, a verification operation of the instructions internal to the edge device and without communicating with the host system, to verify the first software provider signature and the user signature using the first device key and the second device key stored in the edge device, wherein performing the verification operation includes: verifying the first software provider signature of the instructions using the first device key corresponding to the first software provider key; verifying the user signature of the instruction using the second device key corresponding to the user key; and verifying executing, by the edge device, the instructions internal to the edge device and without communication with the host system after verifying both the first software provider signature and the user signature, wherein the execution of the instructions includes: Revoke use of the first device key; and and initiating use of the third device key in place of the first device key.

2. The method of claim 1 , wherein the edge device does not have an internet connection.

3. The method of claim 1 , wherein the edge device is unable to communicate with a third-party verification authority.

4. Executing the verification operation of the instruction to verify the first software provider signature and the user signature using the first device key and the second device key stored on the edge device comprises: verifying the instruction using the first device key using a first boot loader of the edge device; and verifying the instruction using the second device key using a second boot loader of the edge device.

5. The method of claim 4 , wherein executing the instructions includes executing the instructions using the second boot loader.

6. The method of claim 1, wherein the third device key is stored in the edge device before receiving the instruction to disable the first device key.

7. The method of claim 1 , wherein the first device key can be revoked a predetermined number of times.

8. receiving, from the host system in the local network of the edge device, a second set of instructions for updating software installed on the edge device, the second set of instructions including instructions for revoking the second device key; executing the second set of instructions, wherein executing the second set of instructions causes the edge device to: Revoke use of the second device key; and The method of claim 1 , further comprising: initiating use of a fourth device key in place of the second device key.

9. A system for performing key revocation on an edge device, the system comprising: network communications circuitry to a host system in a local network that does not have a connection to the edge device, the edge device having a first device key corresponding to a first software provider key generated by the system and a second device key corresponding to a user key generated by a user system separate from the system; 1. A processor, comprising: generating a first software provider signature using the first software provider key generated by the system and corresponding to the first device key; generating a second software provider signature using a second software provider key corresponding to a third device key to be used in place of the first device key after revocation; using the network communications circuitry to transmit to the host system within the edge device's local network instructions to update software installed on the edge device; the instructions for updating the software include a software image; The instructions for updating the software include: the first software provider signature generated using the first software provider key generated by the system; a user signature generated by the user system, separate from the system, using the user key corresponding to the second device key; Signed by the software image is signed with the second software provider signature; the host system is configured to receive the instructions from the network communication circuitry; receiving the instruction from the host system, and performing a verification operation of the instruction within the edge device and without communicating to the host system to verify the first software provider signature and the user signature, and transmitting, within the edge device and without communicating to the host system, to disable use of the first device key of the edge device and start using a second device key instead of the first device key; and a processor configured to:

10. 10. The system of claim 9, wherein the processor is further configured to sign the instructions using the first software provider key generated by the system.

11. The system of claim 9, wherein the processor is further configured to sign the software image using the second software provider key.

12. 10. The system of claim 9, wherein the processor is further configured to generate the instructions by including in the instructions a key revocation instruction and the software image.

13. The first software provider key is a first private key generated by the software provider system, and the first device key is a public key corresponding to the first private key generated by the software provider system; 2. The method of claim 1, wherein the second software provider key is a second private key generated by the software provider system, and the third device key is a public key corresponding to the second private key generated by the software provider system.

14. The user key of the user system is a private key of the user system, The method of claim 1 , wherein the second device key is a public key corresponding to the private key of the user system.

15. The method of claim 1, further comprising, after executing the instructions, verifying the second software provider signature of the software image using the third device key.

Images