Efficient and secure method and apparatus for firmware update

This relates to a vehicle and, more particularly to, a vehicle configured to perform a secure firmware update. Some examples of the disclosure include receiving a firmware update package including updated firmware for one or more electronic control units (ECUs) of a vehicle. According to the disclosure, the firmware update package can be transmitted to and stored on an untrusted ECU and distributed to one or more target ECUs in a secure firmware update process monitored by a secure ECU.

FIELD OF THE DISCLOSURE

This relates to a vehicle and, more particularly to, a vehicle configured to perform a secure firmware update.

BACKGROUND OF THE DISCLOSURE

Vehicles, such as consumer automobiles, for example, can include one or more electronic systems. In some examples, an electronic system (e.g., one or more lights, indicator systems, actuator systems, etc.) can be controlled by one or more electronic control units (ECUs) included in the vehicle. One or more ECUs can comprise storage or memory with firmware installed thereon. Updates to the firmware can improve ECU efficiency and/or include new functionality for the ECU to perform. In some examples, security of one or more firmware updates can be important to the safety and/or performance of one or more electronic systems of a vehicle. Accordingly, there exists a need in the field of vehicle ECUs for a method and apparatus for efficient, secure firmware updating.

SUMMARY OF THE DISCLOSURE

This relates to a vehicle and, more particularly to, a vehicle configured to perform a secure firmware update. In some examples, a vehicle can include a receiver configured to receive one or more firmware updates in an encrypted package from a server. One or more ECUs within the vehicle can authenticate the package before the firmware updates are distributed to one or more target ECUs of the vehicle. Upon receiving a firmware update, each target ECU can compute and sign a checksum for the firmware update. The checksum and signature can be verified before the firmware is installed, thus ensuring its authenticity.

DETAILED DESCRIPTION

Vehicles, such as consumer automobiles, for example, can include one or more electronic systems. In some examples, an electronic system (e.g., one or more lights, indicator systems, actuator systems, etc.) can be controlled by one or more electronic control units (ECUs) included in the vehicle. One or more ECUs can comprise storage or memory with firmware stored thereon. Updates to the firmware can improve ECU efficiency and/or include new functionality for the ECU to perform. In some examples, security of one or more firmware updates can be important to the safety and/or performance of one or more electronic systems of a vehicle. Accordingly, there exists a need in the field of vehicle ECUs for a method and apparatus for efficient, secure firmware updating.

This relates to a vehicle and, more particularly to, a vehicle configured to perform a secure firmware update. In some examples, a vehicle can include a receiver configured to receive one or more firmware updates in an encrypted package from a server. One or more ECUs within the vehicle can authenticate the package before the firmware updates are distributed to one or more target ECUs of the vehicle. Upon receiving a firmware update, each target ECU can compute and sign a checksum for the firmware update. The checksum and signature can be verified before the firmware is installed, thus ensuring its authenticity.

FIG. 1Aillustrates an exemplary block diagram100according to examples of the disclosure. In some examples, server101can host updated firmware to be installed on one or more ECUs114of vehicle110. Vehicle110can further include a receiver112.

In some examples, receiver112can be operatively coupled to the one or more ECUs114included in vehicle110. The connection between receiver112and ECUs114can be wired or wireless, for example. Receiver112can be communicatively coupled to server101via a wireless network connection (e.g., via Wi-Fi, Bluetooth, a cellular network, or other network connection). In some examples, receiver112can be configured for receiving a firmware update from server101and transmitting the firmware update to the appropriate ECUs114. For example, a firmware update can include a package with a plurality of firmware updates, each update designated for one or more of the plurality of ECUs114included in vehicle110. In some examples, firmware updates for each ECU114can be received one at a time in series, or simultaneously in a parallel operation.

Although block diagram100has been described as shown inFIG. 1A, in some examples, additional or alternative components and/or arrangements are possible. For example, server101can be operatively coupled to a plurality of vehicles. In some examples, a connection between server101and receiver112can be a wired connection. Vehicle110can further include additional components, including but not limited to microcontrollers, actuator systems, and indicator systems, for example. In some examples, ECUs114can include specialized hardware such as processors, controllers, and storage. ECUs114can be configured to control one or more vehicle functions (e.g., power management, actuators, indicators, emergency and/or entertainment features, etc.).

FIG. 1Billustrates an exemplary firmware update process150according to examples of the disclosure. In some examples, receiver112can receive a firmware update from server101(step152of process150). The received firmware can be transmitted to each target ECU114by receiver112, and stored at each target ECU114(step154of process150). The updated firmware can be installed at each target ECU114, allowing the ECUs114to operate with updated firmware (step156of process150). Although process150has been described as shown inFIG. 1B, in some examples, a firmware update process can include additional or alternative steps. In some examples, steps shown here may be deleted or performed in a different order or by different components than those described here without departing from the scope of the claimed subject matter.

In some examples, due to the specialized and limited functionality of one or more ECUs114of vehicle110, the ECUs114may not have sufficient computing power to perform decryption operations, for example. Accordingly, firmware update process150may use unencrypted firmware updates, which may not be secure. In some examples, it can be advantageous to additionally provide a secure ECU configured for performing encrypting operations and securely storing a firmware update for a vehicle, as will be described with reference toFIGS. 2A-2B.

FIG. 2Aillustrates an exemplary block diagram200according to examples of the disclosure. In some examples, server201can host updated firmware to be installed on one or more ECUs214of vehicle210. Vehicle210can further include a secure ECU212that includes a receiver216, processor218, and storage220. Secure ECU212can comprise specialized circuitry to make it resistant to tampering, thus making it secure.

In some examples, secure ECU212can be operatively coupled to the plurality of ECUs214included in vehicle210. The connection can be wired or wireless, for example. Receiver216can be communicatively coupled to server201via a wireless network connection (e.g., via Wi-Fi, Bluetooth, a cellular network, or other network connection). Secure ECU212can further include storage220and processor218. In some examples, a firmware update can include a package including a plurality of firmware updates, each update designated for one or more of the plurality of ECUs214included in vehicle210. Receiver216can be configured for receiving a firmware update from server201. Upon receiving a firmware update, secure ECU212can store the updated firmware in storage220and decrypt (e.g., if the updated firmware is encrypted) and/or authenticate it using processor218. In accordance with a determination that the firmware is authentic, secure ECU212can transmit the firmware update(s) to the appropriate ECUs214. In some examples, firmware updates for each ECU214can be received by receiver216one at a time in series, or simultaneously in a parallel operation.

Although block diagram200has been described as shown inFIG. 2A, in some examples, additional or alternative components and/or arrangements are possible. For example, server201can be operatively coupled to a plurality of vehicles. Vehicle210can further include additional components, including but not limited to microcontrollers, actuator systems, and indicator systems, for example. In some examples, ECUs214can include specialized hardware such as processors, controllers, and storage. ECUs214can be configured to control one or more vehicle functions (e.g., power management, actuators, indicators, emergency and/or entertainment features, etc.).

FIG. 2Billustrates an exemplary firmware update process250according to examples of the disclosure. In some examples, receiver216of secure ECU212can receive a firmware package including updated firmware for one or more ECUs214from server201(step252of process250). The received firmware can be stored at storage220of secure ECU212(step254of process250). Secure ECU212can authenticate (e.g., by verifying a signed key and/or via a decrypting operation) the updated firmware (e.g., using processor218) (step256of process250). If the firmware update is valid, that is, if it has not been compromised during transmission from server201to secure ECU212, authentication can be successful (step258of process250). If authentication is successful, secure ECU212can transmit each firmware update to the one or more appropriate target ECUs214(step260of process250). The updated firmware can be stored at each target ECU214(step262of process250). Once stored, the firmware can be installed at each target ECU214, allowing the ECUs214to operate with updated firmware (step264of process250).

If the firmware update is not valid, that is, if it may have been compromised during transmission from server201to secure ECU212or may not have originated from server201, authentication may not be successful (step258of process250). If authentication is not successful, secure ECU212can erase the firmware without transmitting it to target ECUs214(step266of process250). In some examples, compromised firmware may be resistant to erasure, but can be identified as inauthentic before it is transmitted to target ECUs214, and thus, not transmitted to the target ECUs214. Although process250has been described as shown inFIG. 2B, in some examples, a firmware update process can include additional or alternative steps. In some examples, one or more steps shown here may be deleted or performed in a different order or by different components than those described here without departing from the scope of the claimed subject-matter.

Due to the large secure storage requirements of secure ECU212included in vehicle210and the high cost of secure hardware, the cost of vehicle210may make firmware update process250infeasible. Further, one or more firmware updates may be compromised while being transmitted from secure ECU212to one or more target ECUs214without detection. Therefore, in some examples, it can be advantageous to authenticate and/or decrypt one or more firmware updates using target ECUs214themselves, as will be described with reference toFIGS. 3A-3B.

FIG. 3Aillustrates an exemplary block diagram300according to examples of the disclosure. In some examples, server301can host updated firmware to be installed on one or more ECUs314of vehicle310. ECUs314can each include a processor322. Vehicle310can further include an untrusted ECU312that includes a receiver316, processor318, and storage320. Unlike secure ECU212described with reference toFIGS. 2A-2B, untrusted ECU312may not include specialized tamper-resistant circuitry. Therefore, it can be uncertain if data stored on untrusted ECU312is secure.

In some examples, untrusted ECU312can be operatively coupled to the plurality of ECUs314included in vehicle310. The connection can be wired or wireless, for example. Receiver316can be communicatively coupled to server301via a wireless network connection (e.g., via Wi-Fi, Bluetooth, a cellular network, or other network connection). Untrusted ECU312can further include storage320and processor318. In some examples, a firmware update can include a package including a plurality of firmware updates, each update designated for one of the plurality of ECUs314included in vehicle310. Receiver316can be configured for receiving a firmware update from server301. Upon receiving a firmware update, untrusted ECU312can store the updated firmware in storage320and transmit each firmware update to an appropriate target ECU314. Processors322included in each target ECU314can authenticate and/or decrypt (e.g., if the updated firmware is encrypted) the received firmware updates. In accordance with a determination that the firmware is authentic, the firmware update(s) can be installed and executed at ECUs314. In some examples, firmware updates for each ECU314can be received by receiver316one at a time in series or simultaneously in a parallel operation.

Although block diagram300has been described as shown inFIG. 3A, in some examples, additional or alternative components and/or arrangements are possible. For example, server301can be operatively coupled to a plurality of vehicles. Vehicle310can further include additional components, including but not limited to microcontrollers, actuator systems, and indicator systems, for example. ECUs314can include specialized hardware such as processors, controllers, and storage. ECUs314can be configured to control one or more vehicle functions (e.g., power management, actuators, indicators, emergency and/or entertainment features, etc.). In some examples, though ECUs314may include processors, controllers, and/or storage, an ECU's computing power may be limited to an extent necessary to perform one or more specific vehicle control operations.

FIG. 3Billustrates an exemplary firmware update process350according to examples of the disclosure. In some examples, receiver316of untrusted ECU312can receive a firmware update package including updated firmware for one or more ECUs314from server301(step352of process350). The received firmware can be stored at storage320of untrusted ECU312(step354of process450). Untrusted ECU312can transmit each firmware update to the appropriate target ECUs314(step356of process350). The updated firmware can be stored at each target ECU314(step358of process350). Target ECUs312can authenticate (e.g., by verifying a signed key and/or by decrypting the firmware package) the updated firmware (e.g., using processors322) (step360of process350). If the firmware update is valid, that is, it has not been compromised during transmission from server301to untrusted ECU312and from untrusted ECU312to target ECUs314, authentication at one or more target ECUs314can be successful (step362of process350). If authentication is successful, the updated firmware can be installed at each target ECU314, allowing the ECUs314to operate with updated firmware (step364of process350).

If the firmware update is not valid, that is, it may have been compromised during transmission from server301to untrusted ECU312, compromised during transmission to target ECUs314, or may not have originated from server301, authentication may not be successful (step362of process350). If authentication is not successful, target ECUs314can erase the firmware without installing it (step366of process350). In some examples, compromised firmware may be resistant to erasure, but can be identified as inauthentic before it is installed on target ECUs314, and thus, not installed on target ECUs314.

Although process350has been described as shown inFIG. 3B, in some examples, a firmware update process can include additional or alternative steps. In some examples, steps shown here may be deleted or performed in a different order or by different components than those described here without departing from the scope of the claimed subject-matter. However, due to the large processing requirements of target ECUs314of vehicle310, the manufacturing cost of vehicle310may make firmware update process350infeasible. Therefore, in some examples, it can be advantageous to authenticate a firmware update package using an untrusted ECU, and verify the package with a secure ECU, before transmitting the firmware to one or more target ECUs, as will be described with reference toFIGS. 4A-4B.

FIG. 4Aillustrates an exemplary block diagram400according to examples of the disclosure. In some examples, server401can host updated firmware to be installed on one or more ECUs414of vehicle410. Vehicle410can further include an untrusted ECU412and a secure ECU422. Untrusted ECU can include a receiver416, processor418, and storage420. Secure ECU422can include a processor424. Secure ECU422can comprise specialized tamper-resistant circuitry, thus making data stored on it secure. Untrusted ECU412may not include specialized tamper-resistant circuitry, therefore it can be uncertain if data stored on untrusted ECU412is secure.

In some examples, untrusted ECU412can be operatively coupled to the plurality of ECUs414included in vehicle410. The connection can be wired or wireless, for example. Receiver416can be communicatively coupled to server401via a wireless network connection (e.g., via Wi-Fi, Bluetooth, a cellular network, or other network connection). Untrusted ECU412can further include storage420and processor418. In some examples, a firmware update can include a package including a plurality of firmware updates, each update designated for one or more of the plurality of ECUs414included in vehicle410. Secure ECU422can be operatively coupled to untrusted ECU412.

Receiver416can be configured for receiving a firmware update from server401. Upon receiving a firmware update, untrusted ECU412can store the updated firmware in storage420. The received firmware package can include one or more encrypted files including one or more checksums for each firmware update of the plurality of firmware updates, for example. Processors418included in untrusted ECU412can authenticate (e.g., if the firmware updates are encrypted) each received firmware update of the plurality of received firmware updates. In some examples, authentication can include determining a checksum, as will be described below, for each firmware update. Untrusted ECU412can be further configured for transmitting the encrypted one or more checksums to secure ECU422. Untrusted ECU412can be further configured for receiving, from secure ECU422, one or more distribution commands for each firmware update determined to be authentic (the generation of which by secure ECU422will be described in more detailed below). In response to one or more received distribution commands, untrusted ECU412can transmit one or more respective firmware updates to the appropriate one or more target ECUs414.

Secure ECU422can be configured to decrypt the encrypted checksums provided in the firmware update package and compare the results to the checksums computed by processor418of untrusted ECU412to authenticate each firmware update of the plurality of firmware updates. In some examples, computing a checksum can include applying a checksum function (e.g., including one or more of a parity check, a modular sum or other arithmetic operation, and a position-dependent function) to the bits included in a firmware update. Accordingly, one or more small changes to a firmware update can yield a large difference in checksum value from the result provided from server401, for example. For each firmware update of the plurality of firmware updates, in accordance with a determination that the firmware is authentic, secure ECU422can transmit a distribution command to untrusted ECU412to initiate distribution to one or more target ECUs414. Target ECUs414can be configured to receive, store, and install updated firmware. In some examples, firmware updates for each ECU414can be received by receiver416one at a time in series or simultaneously in a parallel operation.

Although block diagram400has been described as shown inFIG. 4A, in some examples, additional or alternative components and/or arrangements are possible. For example, server401can be operatively coupled to a plurality of vehicles. In some examples, receiver416and server401can be operatively coupled via a wired connection or a wireless connection. Vehicle410can further include additional components, including but not limited to microcontrollers, actuator systems, and indicator systems, for example. In some examples, ECUs414can include specialized hardware such as processors, controllers, and storage. ECUs414can be configured to control one or more vehicle functions (e.g., power management, actuators, indicators, emergency and/or entertainment features, etc.). In some examples, though ECUs414may include processors, controllers, and/or storage, an ECU's computing power may be limited to an extent necessary to perform one or more specific vehicle control operations.

FIG. 4Billustrates an exemplary firmware update process450according to examples of the disclosure. In some examples, receiver416of untrusted ECU412can receive a firmware update package including updated firmware for one or more ECUs414and one or more encrypted files comprising a checksum for each firmware update from server401(step452of process450). The received firmware can be stored at storage420of untrusted ECU412(step454of process450). Untrusted ECU412can compute a checksum for each firmware update of the plurality of firmware updates (step456of process450). Secure ECU422can receive (e.g., from server401by way of untrusted ECU412) one or more encrypted files including the checksums for each firmware update and each checksum computed by untrusted ECU412to verify the checksums and, accordingly, each firmware update included in the package (step458of process450). If the checksums match and, accordingly, the firmware updates are valid, that is, they have not been compromised during transmission from server401to untrusted ECU412, authentication at secure ECU422can be successful (step460of process450). When authentication is successful, the updated firmware can be transmitted (e.g., from untrusted ECU412) to each target ECU414(step462of process450). Target ECUs412can install the firmware to operate with updated firmware (step464of process450).

If one or more checksums may not match, one or more corresponding firmware updates may not be valid. That is, the one or more updates may have been compromised during transmission from server401to untrusted ECU412or may not have originated from server401. In accordance with a determination that one or more checksums may not match, authentication at secure ECU422may not be successful (step460of process450). If authentication is not successful, untrusted ECU412can receive an erase command from secure ECU422and, in response to the erase command, erase the firmware without transmitting it to the target ECUs414(step466of process450). In some examples, compromised firmware may be resistant to erasure, but can be identified as inauthentic before it is transmitted target ECUs414, and thus, not transmitted to target ECUs414. In some examples, the one or more inauthentic firmware updates may not be transmitted to the one or more respective target ECUs414. In some examples, if one or more firmware updates can be inauthentic, all firmware updates may not be transmitted to the one or more respective target ECUs414.

Although process450has been described as shown inFIG. 4B, in some examples, a firmware update process can include additional or alternative steps. In some examples, steps shown here may be deleted or performed in a different order or by different components than those described here without departing from the scope of the claimed subject-matter.

Because each firmware update of the plurality of firmware updates is verified before transmission to one or more target ECUs414, the verification procedure ofFIGS. 4A-4Bmay not be able to detect when one or more updates are compromised during transmission from the untrusted ECU412to one or more target ECUs414. Further, in some examples, authenticating each firmware update prior to transmission to the target ECUs414can cause an unnecessarily large processing overhead, because, generally, a successful firmware attack can be unlikely. Therefore, in some examples, it can be advantageous for a secure ECU to first verify the firmware update package before each firmware update is transmitted to the respective one or more target ECUs, and then allow each target ECU to compute and sign a checksum for its one or more firmware updates, but not install it until the computed checksum is verified at the secure ECU, as will be described with reference toFIGS. 5A-5B.

FIG. 5Aillustrates an exemplary block diagram500according to examples of the disclosure. In some examples, server501can host updated firmware to be installed on one or more ECUs514of vehicle510. Each ECU514can include a bootloader526, storage528, and processor530. Vehicle510can further include an untrusted ECU512and a secure ECU522. Untrusted ECU can include a receiver516, processor518, and storage520. Secure ECU522can include a processor524. Secure ECU522can comprise specialized tamper-resistant circuitry, thus making data stored on it secure. Untrusted ECU512may not include specialized tamper-resistant circuitry, therefore it can be uncertain if data stored on untrusted ECU512is secure.

In some examples, untrusted ECU512, secure ECU522, and a plurality of target ECUs514can be operatively coupled to each other. Each connection can be wired or wireless, for example. Receiver516can be wirelessly coupled to server501via a wireless network connection (e.g., via Wi-Fi, Bluetooth, a cellular network, or other network connection). In some examples, a firmware update can include a package with a plurality of firmware updates, each update designated for one or more of the plurality of ECUs514included in vehicle510. The firmware update package can further include one or more encrypted files comprising a checksum for each firmware update.

Receiver516can be configured for receiving a firmware update package from server501. Upon receiving a firmware update, untrusted ECU512can store the updated firmware in storage520. In some examples, the firmware package can be asymmetrically encrypted. That is, server501can encrypt the firmware package using a first public key and untrusted ECU512can decrypt the firmware update package using a second private key. In some examples, the first public key may not work to decrypt the firmware update package once decrypted. The second private key can be kept secret, thus preventing firmware package from becoming decrypted until it is decrypted by untrusted ECU512. Processor518included in untrusted ECU512can decrypt the firmware package and send an authenticated update command to secure ECU522to request to initiate a firmware update (including, e.g., transmission of each firmware update from untrusted ECU512to each target ECU514)for one or more target ECUs514. In some examples, one or more firmware updates may not begin until untrusted ECU512receives one or more distribution commands after the firmware update package is authenticated by secure ECU522, as will be described in more detail below.

Target ECUs514can be configured to store a received firmware update in storage528, compute a checksum using bootloader526, sign (e.g., with a symmetric key unique to that ECU514) the checksum and transmit it to secure ECU524for authentication. In some examples, computing a checksum can include applying a checksum function (e.g., including one or more of a parity check, a modular sum or other arithmetic operation, and a position-dependent function) to the bits included in a firmware update. Accordingly, one or more small changes to a firmware update can yield a large difference in checksum value from the result provided from server501, for example. In some examples, a checksum function can be computationally simple, and can thus be performed by one or more target ECUs514, even with limited computing resources. Each target ECU514can be further configured to receive an installation command from secure ECU522to install the updated firmware, once it has been fully authenticated by secure ECU522, as will be described below. Installed firmware can be executed by processor530.

Secure ECU522can be configured to verify the update command from untrusted ECU512and the checksums from target ECUs514. For example, secure ECU522can ensure the update command originated from untrusted ECU512and the firmware package originated from server501and arrived uncompromised. Secure ECU522can be further configured for, in accordance with a determination that the update command originated from untrusted ECU512and the firmware package originated from server501and arrived uncompromised, issuing a signed distribution command to untrusted ECU512to distribute the updated firmware to the one or more target ECUs514. Secure ECU522can be configured for, upon receiving one or more checksums from one or more target ECUs514, verifying that the checksums are correct and originated from the correct target ECU514, indicating that the firmware is authentic and safe to install. Secure ECU522can be further configured for sending an installation command to the target ECUs514to install the updated firmware for one or more firmware updates determined to be authentic. Secure ECU522can be further configured for sending an erase command to the target ECUs514to erase the updated firmware when the firmware is determined to be compromised. In some examples, firmware updates for each ECU514can be received one at a time in series or simultaneously in a parallel operation.

Although block diagram500has been described as shown inFIG. 5A, in some examples, additional or alternative components and/or arrangements are possible. For example, server501can be operatively coupled to a plurality of vehicles. In some examples, receiver516and server501can be coupled via a wired connection or a wireless connection. Although a firmware package from server501has been described as being asymmetrically encrypted, in some examples, the package can be symmetrically encrypted. That is, a same secret key can be used by server501to encrypt a firmware update package and the same secret key can be used by untrusted ECU512to decrypt the firmware update package. Although each firmware update has been described as being symmetrically encrypted, in some examples, asymmetric encryption is possible. Each firmware update can be encrypted by server501prior to transmission or by untrusted ECU512or secure ECU522upon receipt. In some examples, secure commands passed between untrusted ECU512, secure ECU522, and target ECUs514can be signed (e.g., with a symmetric or asymmetric key) prior to transmission and authenticated upon receipt. Vehicle510can further include additional components, including but not limited to microcontrollers, actuator systems, and indicator systems, for example. ECUs514can be configured to control one or more vehicle functions (e.g., power management, actuators, indicators, emergency and/or entertainment features, etc.).

FIG. 5Billustrates an exemplary firmware update process550according to examples of the disclosure. In some examples, receiver516of untrusted ECU512can receive a firmware package including updated firmware for one or more ECUs514and one or more encrypted files comprising a checksum for each firmware update from server501(step552of process550). The firmware update can be stored at storage520of untrusted ECU512in some examples. Untrusted ECU can decrypt (e.g., using processor518) the firmware package and send a signed update command to secure ECU522requesting to initiate a firmware update process (step554of process550). Secure ECU522can decrypt and/or authenticate the request to determine whether the firmware package and the request are authentic. If the firmware package and the request are authentic, authentication at secure ECU522can be successful (step556of process550). If authentication is successful, untrusted ECU512can receive a signed distribution command from secure ECU522and, in response to the received distribution command, transmit one or more firmware updates of the plurality of firmware updates to the appropriate target ECUs514(step558of process550). Each target ECU514can compute and sign a checksum for its received firmware update and transmit the signed checksum to secure ECU522for verification (step562of process550). If the secure ECU522determines that the signature is authentic (e.g., by decrypting an encrypted signature) and the checksum is valid (e.g., by comparing the checksum computed by the target ECU514to the checksum provided by the server501), verification can be successful (step562of process550). If verification at secure ECU522is successful, secure ECU522can send a signed installation command to the one or more target ECUs514to install the firmware (step564of process550).

If the request from untrusted ECU512to initiate firmware distribution is not successful, it is possible the request may not have originated from untrusted ECU512or the firmware package may be compromised or may not have originated from server501(step556of process550). Likewise, if a checksum from a target ECU514is not successful, it is possible that the checksum may not have originated from the correct ECU514or the firmware update may be inauthentic (step562of process550). If authentication at step556or562is not successful, secure ECU552can issue a signed erase command to one or more of untrusted ECU512and one or more secure ECUs522to erase the firmware (step568of process550). If step556fails, the erase command can be transmitted from secure ECU522to untrusted ECU512and the firmware can be erased from untrusted ECU512before it is distributed to target ECUs514, for example. In some examples, compromised firmware may be resistant to erasure, but can be identified as inauthentic before it is installed on target ECUs514. If step562fails, the erase command can be transmitted to one or more target ECUs514corresponding to one or more failed checksums and firmware can be erased from one or more target ECUs514before it is installed and/or executed, for example. Optionally, if step566fails, the erase command can additionally be transmitted to untrusted ECU512. In some examples, compromised firmware may be resistant to erasure, but can be identified as inauthentic before it is executed on target ECUs514.

Although process550has been described as shown inFIG. 5B, in some examples, a firmware update process can include one or more additional or alternative steps. In some examples, one or more steps shown here may be deleted or performed in a different order or by different components than those described here without departing from the scope of the claimed subject-matter.

FIG. 6illustrates a block diagram600of an exemplary vehicle according to examples of the disclosure. Block diagram600can include server601communicatively coupled to vehicle610. Vehicle610can include untrusted ECU612, secure ECU622, a plurality of additional ECUs614, including actuator system ECUs626, indicator system ECUs628, and other ECUs630. Untrusted ECU612can include receiver616. Secure ECU622can include processor624. Vehicle610can further include one or more additional ECUs614and one or more actuator systems640, indicator systems650, and other systems660. Exemplary actuator systems640include motor641, engine642, battery system643, transmission gearing644, suspension setup645, brakes646, steering657, and doors648. Exemplary indicator systems650include speaker651, light653, display655, tactile indicator(s)657, and one or more mirrors649. Other systems660can include, for example, one or more cameras661, navigation663, climate control665, seating667, and one or more safety systems669(e.g., airbags, stabilization systems, seatbelts, etc.).

In some examples, receiver616included in untrusted ECU612can be communicatively coupled to server601. Untrusted ECU612can be operatively coupled to one or more of secure ECU622and other ECUs614to perform a firmware update process to update the firmware on one or more of other ECUs614according to one or more examples described with reference toFIGS. 1-5. One or more additional ECUs614can be operatively coupled to one or more actuator systems640, indicator systems650, and/or other systems660. In some examples, one ECU can control multiple systems and one system can be controlled in part by multiple ECUs. Additional and alternative systems, components, and configurations are possible.

Therefore, according to the above, some examples of the disclosure are related to a vehicle, comprising: an untrusted electronic control unit (ECU) comprising a receiver, a processor, and a memory, the receiver configured for receiving from a secure server a firmware update package including one or more firmware updates, and the memory of the untrusted ECU configured to store the firmware update package; a secure ECU operatively coupled to the untrusted ECU, the secure ECU configured for authenticating the firmware update package; and one or more target ECUs, each operatively coupled to the untrusted ECU and to the secure ECU, each respective target ECU comprising a bootloader configured for computing a checksum for a respective firmware update of the one or more firmware updates and signing the checksum with a unique key associated with the respective target ECU. Additionally or alternatively to one or more of the examples disclosed above, the firmware update package is encrypted with an asymmetric key and each of the one or more firmware updates is encrypted with the unique key corresponding to a respective target ECU of the one or more target ECUs. Additionally or alternatively to one or more of the examples disclosed above, the untrusted ECU is further configured for: decrypting the firmware update package; and transmitting a signed update command to the secure ECU. Additionally or alternatively to one or more of the examples disclosed above, the secure ECU is configured for: receiving a signed update command from the untrusted ECU, the signed update command indicative of the received firmware update package; authenticating the signed update command; and in accordance with a determination that the signed update command is authentic, transmitting a signed distribution command to initiate a transmission of one or more firmware updates to one or more target ECUs. Additionally or alternatively to one or more of the examples disclosed above, the secure ECU is configured for: in accordance with a determination that the signed updated command is inauthentic, transmitting a signed erase command to the untrusted ECU to initiate an erasure of the firmware update package. Additionally or alternatively to one or more of the examples disclosed above, the secure ECU is configured for: receiving the signed checksum from one or more target ECUs; verifying a signature of the signed checksum; verifying a result of the signed checksum; and in accordance with a determination that the signature is valid and the result is correct, transmitting one or more installation commands to the one or more target ECUs to install a respective firmware update corresponding to the signed checksum. Additionally or alternatively to one or more of the examples disclosed above, the secure ECU is configured for: in accordance with a determination that the signature is not valid or the result is incorrect, transmitting one or more erase commands to the one or more target ECUs to erase a respective firmware update corresponding to the signed checksum. Additionally or alternatively to one or more of the examples disclosed above, each unique key associated with each target ECU is a symmetric key.

Some examples of the disclosure are related to a method for updating firmware at a vehicle, the method comprising: receiving, from a secure server, a firmware update package including one or more firmware updates; storing the firmware update package at a memory of an untrusted electronic control unit (ECU); authenticating, with a secure ECU, the firmware update package; in accordance with a determination that the firmware update package is authentic: transmitting one or more firmware updates included in the firmware update package to one or more respective target ECUs; computing, with a bootloader included in a target ECU of the one or more respective target ECUs, a checksum for a respective firmware update; and signing, with the bootloader, the checksum using a unique key associated with the target ECU. Additionally or alternatively to one or more of the examples disclosed above, the firmware update package is encrypted with an asymmetric key and each of the one or more firmware updates is encrypted with the unique key corresponding to the respective target ECU. Additionally or alternatively to one or more of the examples disclosed above, the method further comprises, at the untrusted ECU: decrypting the firmware update package; and transmitting a signed update command to the secure ECU. Additionally or alternatively to one or more of the examples disclosed above, the method further comprises, at the secure ECU: receiving a signed update command from the untrusted ECU, the signed update command indicative of the received firmware update package; authenticating the signed update command; and in accordance with a determination that the signed update command is authentic, transmitting a signed distribution command to initiate a transmission of one or more firmware updates to one or more target ECUs. Additionally or alternatively to one or more of the examples disclosed above, the method further comprises, at the secure ECU:in accordance with a determination that the signed updated command is inauthentic, transmitting a signed erase command to the untrusted ECU to initiate an erasure of the firmware update package. Additionally or alternatively to one or more of the examples disclosed above, the method further comprises, at the secure ECU: receiving a signed checksum from one or more target ECUs; verifying a signature of the signed checksum; verifying a result of the signed checksum; and in accordance with a determination that the signature is valid and the result is correct, transmitting one or more installation commands to the one or more target ECUs to install a respective firmware update corresponding to the signed checksum. Additionally or alternatively to one or more of the examples disclosed above, the method further comprises, at the secure ECU: in accordance with a determination that the signature is not valid or the result is incorrect, transmitting one or more erase commands to the one or more target ECUs to erase a respective firmware update corresponding to the signed checksum. Additionally or alternatively to one or more of the examples disclosed above, each unique key associated with each target ECU is a symmetric key.

Some examples of the disclosure are related to a non-transitory computer-readable medium including instructions, which when executed by one or more processors, cause the one or more processors to perform a method for updating firmware at a vehicle, the method comprising: receiving, from a secure server, a firmware update package including one or more firmware updates; storing the firmware update package at a memory of an untrusted electronic control unit (ECU); authenticating, with a secure ECU, the firmware update package; in accordance with a determination that the firmware update package is authentic: transmitting one or more firmware updates included in the firmware update package to one or more respective target ECUs; computing, with a bootloader included in a target ECU of the one or more respective target ECUs, a checksum for a respective firmware update; and signing, with the bootloader, the checksum using a unique key associated with the target ECU.