SOFTWARE AUTHENTICATION BEFORE SOFTWARE UPDATE

Abstract

Procedure, comprehensive: Initiating a programming process of an electronic control unit (114) of a vehicle by a service aid (206) which is communicatively connected to the electronic control unit (114) via a diagnostic connection unit (108) and a vehicle bus; Authenticate, by means of the service tool (206), a software update for the electronic control unit (114), using an authentication key received by the service tool (206) from the electronic control unit (114); and In response to successful authentication, the software update is sent from the service tool (206) via the vehicle bus to the electronic control unit (114).

Description

TECHNICAL AREA

[0001] The present disclosure relates to software updates for a vehicle and, in particular, to performing software authentication before performing software updates. BACKGROUND

[0002] In-vehicle software can benefit from various security measures, as the installation of unauthorized software is undesirable. One commonly used measure is the application of a digital signature scheme to ensure that the software is authentic and has not been tampered with. When in-vehicle software for an electronic control unit (ECU) is ready for an update, the update procedure may involve overwriting the ECU with the new software and subsequently authenticating the newly installed software using the ECU.

[0003] In a US 2006 / 0259207A1 ECU, a flash ROM has a main memory area for storing a current version of an application program and a submemory area for storing an updated program version containing updated points of the current program version. A rewrite tool performs a program rewrite operation that includes: memory processing to store the updated program version in the submemory area and a memory switch operation in which, after the updated program version is successfully written to the submemory area, the submemory area where the storage of the updated program version was completed is switched from a memory area currently used as main memory to a new main memory area. If the write to the submemory area fails, the switch is not performed.

[0004] A method for updating a vehicle ECU according to US 2011 / 0320089A1 includes establishing communication between a vehicle's data communication module and an update server over a cellular network; validating the vehicle using a key exchange protocol between the data communication module and the update server; and sending update information from the update server over the cellular network to the vehicle's data communication module, the update information being configured for use in updating the vehicle ECU.

[0005] US 2014 / 0075517A1 discloses a system and a procedure for bypassing a security code to allow the installation of development software on a production electronic control unit (ECU) without authenticating the software. The procedure involves requesting information from the ECU and generating an information ticket in the ECU in response to the request, which identifies the ECU. The information ticket is sent to a secure server, which generates an authentication ticket. This ticket identifies the ECU from the information ticket and generates a security code for the ticket. The authentication ticket is provided to the ECU, and if the security code is verified by the ECU, the ECU allows the development software to be installed. SUMMARY

[0006] The present invention relates to a method and a vehicle system with the features of the independent claims. Advantageous embodiments of the invention are described in the dependent claims.

[0007] Accordingly, a method for updating software for a vehicle's electronic control unit (ECU) includes initiating a programming process of a vehicle's electronic control unit (ECU) by an update device that is communicatively connected to the ECU via a vehicle bus; authenticating a software update to be installed on the ECU by the update device using an authentication key received from the ECU; and, in response to successful authentication, sending the software update from the update device via the vehicle bus so that it can be applied to the ECU.

[0008] The procedure may further include the update device requesting the authentication key from the ECU via the vehicle bus; and the ECU validating a checksum of the software update in response to receiving the software update. The procedure may also include generating a notification indicating the authentication result. The authentication may involve authenticating a digital signature of the software update using the authentication key, where the authentication key is a public key, and the digital signature is applied to the software update by an issuer of the software update using a private key corresponding to the authentication key.

[0009] The procedure may further include: determining an updated version of the ECU software update; determining a current version of the ECU software currently installed in the ECU; comparing the update version with the current version to obtain a comparison result; and, based on the comparison result, deciding whether to send the authentication key from the ECU to the overwrite device. The procedure may further include issuing a message based on the comparison result. The procedure may further include the update device requesting an authentication key from the ECU in response to a software update version not matching a current version of the software installed in the ECU.

[0010] The overwrite device can be connected to the vehicle's internal network using an On-Board Diagnostics 2 (OBD2) connector. The method can also involve receiving the ECU software update via a telematics control unit (TCU) over a wireless network. The TCU can be the overwrite device.

[0011] In one or more illustrative embodiments, a vehicle system includes a telematics control unit (TCU) connected to an in-vehicle network and configured to: receive a software update for an electronic control unit (ECU) over a wireless network; initiate a programming operation with the ECU over the in-vehicle network; authenticate the software update using an authentication key received from the ECU over the in-vehicle network to obtain an authentication result; and, in response to the authentication result indicating successful authentication, send the software update over the in-vehicle network to the ECU to cause the ECU to overwrite a memory of the ECU with the software update.

[0012] The TCU can further be configured to receive the authentication key from the ECU from a memory within the TCU, whereby the authentication key is stored in memory from the TCU to the ECU following a previous software update application. The TCU can also be configured to display a notification indicating the authentication result. The TCU can further be configured to authenticate a digital signature of the software update using the authentication key, where the authentication key is a public key, and the digital signature is applied to the software update by an issuer of the software update using a private key that corresponds to the authentication key.

[0013] The TCU is further configured to: determine the update version of the software update before receiving it; determine the current software version installed in the ECU; compare the update version with the current version to obtain a comparison result; and, based on the comparison result, decide whether to receive the software update. The TCU can also be configured to reject the software update in response to an update version being incompatible with the current version of the software installed in the ECU. The wireless network can be at least one of a cellular network, a WLAN network, or a Bluetooth network.

[0014] In one or more illustrative embodiments, a device for overwriting software for a vehicle's electronic control unit (ECU) includes a connection unit configured to couple the device to the vehicle's internal network; a memory configured to store a software update for an electronic control unit (ECU); and a processor configured to: initiate a programming operation to the ECU via the connection unit; authenticate the ECU software update using an authentication key to obtain an authentication result; and, if the authentication result indicates successful authentication, send the ECU software update to the ECU via the vehicle's internal network to cause the ECU to perform the overwrite with the ECU software update.

[0015] The device may further include a communication device configured to download the ECU software update. The processor may also be configured to authenticate a digital signature of the software update using the authentication key, wherein the authentication key is a public key, and the digital signature is applied to the software update by an issuer of the software update using a private key corresponding to the authentication key. The processor may further be configured to determine whether to obtain the authentication key from the ECU in response to a determination that a version of the ECU software update is more extensive than a current version of the software installed on the ECU.

[0016] The details of one or more implementations are listed in the attached drawings and the description below. Further features and advantages can be found in the description, the drawings, and the claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] For a better understanding of the invention and to show how it can be carried out, embodiments thereof are described here exclusively as non-limiting examples, with reference to the accompanying drawings, in which: Fig. 1 represents an exemplary in-vehicle system of an embodiment of the present disclosure; Fig. 2A represents an exemplary topology diagram of the vehicle's internal system configured to perform an ECU update of an embodiment of the present disclosure; Fig. 2B represents an exemplary topology diagram of the vehicle's internal system configured to perform an ECU update of an alternative embodiment of the present disclosure; Fig. 3 represents an exemplary data flow diagram of the vehicle's internal system configured to perform the ECU update of an embodiment of the present disclosure; and Fig. Figure 4 presents an exemplary flowchart of the procedure that performs the ECU update of an embodiment of the present disclosure. DETAILED DESCRIPTION

[0018] Detailed embodiments of the present invention are disclosed herein as required; however, it is understood that the disclosed embodiments are merely examples of the invention, which can be implemented in various and alternative forms. The figures are not necessarily to scale; some features may be enlarged or reduced to show details of certain components. Accordingly, the specific structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a representative basis to teach those skilled in the art the diverse uses of the present invention.

[0019] Vehicle ECUs have limited computing resources, such as limited memory and processing power. These limitations can increase the difficulty of implementing resource-intensive security measures, such as a public-key infrastructure, within the ECU. Furthermore, if software updates are authenticated after the software has been installed on the ECU, such a system limits the ECU's ability to continue operating if the software authentication fails. Instead, if authentication fails, the system may restart the update process and attempt to overwrite the software on the ECU again. This can be inefficient, and the ECU may fail to boot properly if the update process fails.Furthermore, it is possible that inauthentic software was installed on the ECU without having been checked before installation.

[0020] An enhanced ECU software update procedure can be performed by a service tool connected to an in-vehicle network, such as a Controller Area Network (CAN), via a diagnostic port, such as an On-Board Diagnostics 2 (OBD2) connector. Alternatively, the service tool can connect to the in-vehicle network via other wired and / or wireless connections, such as USB, Bluetooth, Wi-Fi, satellite, and / or any other means configured to connect to the in-vehicle network. The service tool can be a computer with the necessary software loaded on it. If the update is successful, the service tool can terminate the process and notify the user of the successful update.If the update fails at any step, the update process is interrupted and the user / technician is notified of the update status. The user can then decide what to do next.

[0021] In an alternative example, the vehicle's onboard system may include a telematics control unit (TCU). The TCU may be configured to download the ECU software update from a software repository via a wireless connection, such as a cellular network. Upon completion of the download, the onboard system may notify the user of the update's availability and request user consent to perform the update. This consent may be obtained through a user interface, such as the vehicle's human-machine interface (HMI). Alternatively, the onboard system may perform the update automatically at a convenient time, such as when the vehicle is parked or the key is removed.Success or failure, or other status information regarding the update, can be provided to the user through the user interface. Further aspects of the disclosure are described in more detail here.

[0022] Fig. Figure 1 represents an exemplary in-vehicle system 100 of an embodiment of the present disclosure. According to the illustration, the in-vehicle system 100 includes an in-vehicle network 102, a TCU 104, a gateway device 106, a diagnostic connection unit 108, an infotainment system 110, a user interface 112, one or more ECUs 114 (of which only one is shown for clarity), a USB port 116, and a wireless transmitter / receiver 118. The in-vehicle network 102 can be configured to connect other devices of the in-vehicle system 100. In some examples, the in-vehicle network 102 can be a CAN, an Ethernet network, or a Media Oriented System Transfer (MOST) network. The infotainment system 110 can include a user interface 112.As an example, the user interface 112 can include a display screen, a touchscreen, a set of segmented displays, and one or more buttons or other controls. The USB port 116 can enable the connection of storage devices to the infotainment system 110. It is worth noting that the modularization of the in-vehicle system 100 is merely exemplary, and more, fewer, and / or differently partitioned devices of the in-vehicle system 100 can be used. In one example, the gateway device 106 could be an ECU configured to connect and transmit messages between different system buses, such as messages interacting between a high-speed CAN bus, a low-speed CAN bus, and / or Ethernet.In some examples, the gateway device 106 can be an external device connected to the vehicle via the diagnostic port unit 108. The diagnostic port unit 108 can, for example, be an OBD2 port unit.

[0023] Fig. Figure 2A shows an example topology diagram of the vehicle's internal system 100, which is configured to perform an ECU update. In system 100, the diagnostic connection unit 108 is connected to the gateway device 106 via the vehicle's internal network 102. The gateway device 106 is also connected to the ECU 114 via the vehicle's internal network 102.

[0024] A service tool 206 can be configured to provide the vehicle 202 with software updates from a software repository 204. For this purpose, the service tool 206 can be configured to establish a connection to the vehicle's internal network 102 of the vehicle's internal system 100. In many examples, the service tool 206 can be configured to establish a connection to the vehicle's internal network 102 via the diagnostic port 108. The service tool 206 can receive a software update for the vehicle 202 from the software repository 204 via a wired connection 210 and / or a wireless connection 208 via a communication network. Alternatively, the software update can be pre-installed in the service tool 206.For example, the service aid 206 can be implemented as various types of computing devices, such as a laptop computer, a desktop computer, a tablet, a dedicated device, an automotive diagnostic aid / scanner, a Personal Digital Assistance (PDA), an Integrated Diagnostic Service (IDS) device, and / or any other device that can be configured to connect to the diagnostic terminal unit 108 and be capable of downloading and providing software for the ECU 114.

[0025] The gateway device 106 can be configured to control communication between the service tool 206 and the ECU 114 via the vehicle's internal network 102. Alternatively, the service tool 206 can be configured to connect to the ECU 114 via the vehicle's internal network 102 without a connection through the gateway device 106. For example, the service tool 206 can be configured to connect to the vehicle's internal network 102 via the USB port 116, the wireless transmitter / receiver 118, or another vehicle connection unit through which software updates can be provided.

[0026] Service Utility 206 can be configured to receive an authentication key from the ECU 114 to authenticate the software update. For example, the authentication key could be a public key stored in the ECU 114 to verify software updates signed with a corresponding private key securely held by the software update publishers. If the authentication process is successful, Service Utility 206 can be configured to send the software update to the ECU 114 to proceed with the update. If the authentication process fails, Service Utility 206 can be configured to interrupt the update process and notify the user of the authentication failure.In one example, the service aid 206 can use a built-in screen and / or speaker to notify the user of the failure condition. Alternatively, the vehicle's in-vehicle system 100 can be configured to notify the user through the user interface 112 of the infotainment system 110.

[0027] Fig. Figure 2B presents an alternative example topology diagram of the vehicle's in-vehicle system 100, configured to perform an ECU update. Compared to the one in Fig. In the example shown in 2A, the update in the example can be performed after Fig. 2B can be performed by the TCU 104 without a connected service aid 206. Instead, the TCU 104 can be configured to assume the role of the service aid 206 and receive the software update from the software repository 204 via a wireless connection 214. For example, the wireless connection 214 can be a cellular network. Alternatively, the wireless connection 214 can be a Bluetooth, WLAN, satellite, and / or any other wireless connection through which the software updates can be provided. The TCU 104 can be connected to the ECU 114 via the vehicle's internal network 102 through the gateway device 106. Alternatively, the TCU 104 can be configured to connect to the ECU 114 via the vehicle's internal network 102 without a connection through the gateway device 106.

[0028] In one example, the TCU 104 could be a separate device containing a cellular modem and connected to the vehicle's internal network 102. Alternatively, the operational steps described here as being performed by the TCU 104 could be performed wholly or partially by the vehicle's infotainment system. For example, the Ford SYNC® system developed by Ford Motor Company could use a paired and connected mobile phone to download, authenticate, and deliver authenticated updates to the ECU 114.

[0029] To continue with the example of TCU 104, TCU 104 can be configured to receive an authentication key from ECU 114 and authenticate the software update using this key. If the authentication process is successful, TCU 104 can be configured to send the software update to ECU 114 to continue the update. If the authentication process fails, TCU 104 can be configured to interrupt the update process and notify the user of the failure condition. In some examples, TCU 104 can be configured to notify the user of the failure condition through the infotainment system 110's user interface 112, for example, by providing a visual or audible warning.

[0030] Fig. Figure 3 represents an exemplary data flow 300 of an operation of the TCU 104, which performs a software update for the ECU 114. While in this example certain operating steps are explained as being carried out by the TCU 104, it should be noted that in other examples a service aid 206 connected to the diagnostic connection unit 108 can carry out the operating steps that are indicated as being carried out by the TCU 104.

[0031] Data flow 300 can begin when TCU 104 requests the authentication key 302 from ECU 114 via the vehicle's internal network 102. The authentication key request can be triggered in response to input provided to the user interface 112 by a user / technician requesting an update process. Alternatively, TCU 104 can be integrated into the vehicle's telematics system 100, allowing TCU 104 to receive user / technician input via a telematics control unit input device, such as a main unit display.As another example, the authentication key request by the TCU 104 or the vehicle's internal system 100 can be triggered automatically in response to a determination by the vehicle 100 that the vehicle systems are not in use, such as when the vehicle 100 is parked or the key has been removed. It should be noted that the software update may have been downloaded to the TCU 104 prior to the authentication key 302 being requested. This download may have occurred as a result of the TCU 104 regularly checking for updates or in response to a user command (entered, for example, via the user interface 112).

[0032] In response to a request for authentication key 302, the ECU 114 can send authentication key 304 to the TCU 104. For example, authentication key 304 could be a public key stored on the ECU 114 for use in authenticating digital signatures of software updates. Upon receiving authentication key 304 from the ECU 114, the TCU 104 can authenticate the software update's digital signature to determine if the update is authentic and unmodified.It should be noted that, since the authentication process is performed in the TCU 104 and the TCU 104 can incorporate larger computing resources than the ECU 114 in many cases, more complex authentications can be performed using the TCU 104 and within a shorter time than approaches that use the computing resources of the ECU 114 for authenticating software updates.

[0033] In response to successful authentication of the software update by the TCU 104, the TCU 104 initiates a programming operation 305 with the ECU 114. For example, programming operation 305 can enable Unified Diagnostic Services (UDS) to be executed. Additionally or alternatively, programming operation 305 can define various conditions that must be met before the ECU 114 can be switched to a mode in which software updates can be applied to it. For example, in response to receiving the request from the TCU 104 to initiate programming operation 305, the ECU 114 can acknowledge one or more conditions that must be set for programming operation 305 to be executed.In one example, ECU 114 can be configured to prevent the initiation of programming operation 305 while the vehicle key is inserted and / or the vehicle is in motion, to ensure that ECU 114 functionality remains available while the vehicle 100 is in use. In response to ECU 114 initiating programming operation 305, TCU 104 can send software update 306 to ECU 114 for application to its memory. ECU 114 can receive the software update and replace the current software version installed in its memory with software update 306, which has already been authenticated by TCU 104.In response to ECU 114 completing the overwrite of its memory with the new software update 306, ECU 114 can perform a completeness validation to verify that the software update 306 was installed correctly. For example, the completeness validation might involve checking a checksum of the software update against a checksum value provided to ECU 114 with the software update. Upon successful completion of the completeness validation, ECU 114 can send a "Finish Operation 310" message to TCU 104 to complete the programming operation 305.

[0034] It should be noted that while the TCU 104 is used in this example to update the ECU 114, other components, such as the service tool 206, can also be used to perform the update. Furthermore, other components and / or parts of the vehicle's internal system 100 that have available computing resources and are connected to the vehicle's internal network 102 can be used in combination with the TCU 104 or the service tool 206 to perform the validation and control of the software update for the ECU 114, instead of using the computing resources of the ECU 114 to authenticate the software update.

[0035] Fig.Figure 4 presents an exemplary flowchart 400 of the procedure for performing a software update of the ECU 114. In one example, the procedure can be performed by the TCU 104. However, it should also be noted that the operational steps of the procedure, which are described as being performed by the TCU 104, are performed in other examples by the service tool 206 and / or other components and / or parts of the vehicle's internal system 100.

[0036] The procedure can begin at S402 after the TCU 104 has been switched on. At S404, the TCU 104 can receive the software update from the software repository 204 via a wireless connection 214. In response to receiving the software update, the TCU 104 can initiate a software update request to the ECU 114. In response to the software update request, the ECU 114 can send a version identifier of the software currently installed on the TCU 104 to the TCU 104. At S406, the TCU 104 can use the version identifier to prepare for the update by comparing the version identifier of the software currently installed on the ECU 114 with the version of the software update to determine if the software update version is higher and therefore suitable for installation.Alternatively, the TCU 104 can acquire the version identifier of the software version currently installed on the ECU 114 in advance, e.g., as part of the regular request by the TCU 104 for available software updates, in order to enable the TCU 104 to use the version identifier to query whether a more recent software version is available for download and installation on the ECU 114.

[0037] If the TCU 104 determines that a software update is compatible and / or necessary, it can notify the user of the update's availability. For example, the TCU 104 can provide the user with a notification via the infotainment system 110 and / or the user interface 112 to inform them that the software update is available. Using this notification, the user can respond, for example, via the user interface 112, and provide confirmation to proceed with the S408 update. Alternatively, the TCU 104 can perform the software update automatically when the vehicle is not in use, such as when the car is parked and / or the key is removed.If the TCU 104 or the user decides not to continue the update, the TCU 104 can interrupt the update process and notify the user of the unrecognized status of the available software update at S424. The process can end at operating step S430.

[0038] If the user decides to proceed with the software update on ECU 114, TCU 104 can obtain the authentication key from ECU 114 at S410. For example, the authentication key may have been previously stored on ECU 114 (e.g., in a read-only memory of ECU 114 during manufacturing, as part of a previous software update, etc.). Alternatively, the authentication key may have been previously acquired by ECU 114 (e.g., during a previous software update cycle) and stored in memory on TCU 104. In such a case, TCU 104 can determine at S410 that the authentication key is already available and proceed without requesting it from ECU 114.In response to receiving the authentication key, the TCU 104 can authenticate the software update at S412. For example, the TCU 104 can authenticate the software update's digital signature to verify that the software update is authentic and has not been corrupted or tampered with (e.g., correctly signed using the software update author's private key, which corresponds to the authentication key, and is not available to third parties). In another example, the authentication process might involve one or more digital signature schemes (DSS), an elliptic curve digital signature algorithm, and / or another asymmetric key algorithm.If the authentication process fails, the update process may be interrupted and the user may be notified at S424. Since the software update has not yet been transferred to the ECU 114 at this point in the procedure, the ECU 114 is protected from potential problems associated with receiving a failed software update. Even if the TCU 104 were to download an inauthentic software update, which could potentially damage the vehicle and cause inconvenience or strand the user, these problems can be prevented by the current procedure.

[0039] If authentication is successful, the process continues, and the ECU 114 can begin programming operation S415 to receive the software update. During programming operation S416, the TCU 104 can instruct the ECU 114 to replace the current software version with the updated software. Generally, the overwriting step with authentic software updates is stable and secure. However, if the overwriting step fails for any reason, such as a communication failure, the TCU 104 may interrupt the update process in response to the communication problem and notify the user of the failure at S424. In such a situation, the user can choose to restart the update process from step S405, as the software has already been downloaded to the TCU 104.Alternatively, the user can be given the option to restart from step S416 to overwrite the already authenticated software update. As another possibility, the user can also be given the option to restart the process from the beginning of step S402.

[0040] If the overwrite step S416 is successful, the ECU 114 can perform a completeness validation to verify that the software update was installed correctly at S420. In one example, the completeness validation might involve a checksum calculation. Example checksums for use in such a validation could include, as some non-restrictive options, CRC, MD5, SHA1SUM, or SHA2SUM. If the ECU's completeness evaluation step S420 fails, the software update is not installed correctly, and the ECU 114 can notify the user of the failure in S424. If such a failure occurs, the user can choose to restart the process. If the installed software update passes the evaluation at step S422, the ECU 114 can optionally inform the user that the update process was successful, and the process ends in S430.

[0041] Although exemplary embodiments have been described above, this was not done with the intention that these embodiments describe all possible forms of the invention. Rather, the terms used in the patent specification are descriptive rather than limiting, and it is understood that various modifications can be made without deviating from the spirit and scope of the invention. Furthermore, the features of different implemented embodiments can be combined to form further embodiments of the invention.

Claims

[1] Procedure, encompassing: Initiating a programming process of an electronic control unit (114) of a vehicle by a service aid (206) which is communicatively connected to the electronic control unit (114) via a diagnostic connection unit (108) and a vehicle bus; Authenticate, by means of the service tool (206), a software update for the electronic control unit (114), using an authentication key received by the service tool (206) from the electronic control unit (114); and In response to successful authentication, the software update is sent from the service tool (206) via the vehicle bus to the electronic control unit (114). [2] The method of claim 1, further comprising: Requesting the authentication key via the vehicle bus from the electronic control unit (114) by an update device; and Validating a checksum of the software update by the electronic control unit (114) in response to receiving the software update by the electronic control unit (114). [3] Method according to claim 1, further comprising generating a notification indicating a result of the authentication. [4] Method according to claim 1, wherein the authentication includes authenticating a digital signature of the software update using the authentication key, wherein the authentication key is a public key, and wherein the digital signature is applied to the software update by an issuer of the software update using a private key corresponding to the authentication key. [5] The method of claim 1, further comprising: Determining an update version of the software update; Determine the current version of the software installed in the electronic control unit (114); Comparing the updated version with the current version to obtain a comparison result; and Based on the comparison result, identify whether the authentication key should be requested from the electronic control unit (114) by the update device. [6] The method of claim 5, further comprising issuing a communication based on the comparison result. [7] Method according to claim 1, further comprising a request for an authentication key from the electronic control unit (114) by the update device in response to the fact that an update version of the software update does not match a current version of the software installed in the electronic control unit (114). [8] Method according to claim 1, wherein the update device is connected to the vehicle bus of the vehicle using an on-board diagnostics 2 connection unit. [9] Method according to claim 1, further comprising receiving the software update using a telematics control unit (104) via a wireless connection (214). [10] Method according to claim 9, wherein the update device is the telematics control unit (104). [11] Vehicle system (100), comprising: A telematics control unit (104) connected to an in-vehicle network (102) is configured to to receive a software update for an electronic control unit (114) via a wireless network (214); to initiate a programming process with the electronic control unit (114) via the vehicle's internal network (102); the software update using an authentication key, to authenticate the data received via the vehicle's internal network (102) from the electronic control unit (114) in order to obtain an authentication result; and In response to the authentication result indicating successful authentication, the software update is sent via the vehicle's internal network (102) to the electronic control unit (114) to cause the electronic control unit (114) to overwrite a memory of the electronic control unit (114) with the software update. [12] Vehicle system (100) according to claim 11, wherein the telematics control unit (104) is further configured to obtain the authentication key from the electronic control unit (114) from a memory of the telematics control unit (104), wherein the authentication key is stored in the memory from the telematics control unit (104) to the electronic control unit (114) following the application of a previous software update. [13] Vehicle system (100) according to claim 11, wherein the telematics control unit (104) is further configured to display a notification indicating the authentication result. [14] Vehicle system (100) according to claim 11, wherein the telematics control unit (104) is further configured to authenticate a digital signature of the software update using the authentication key, wherein the authentication key is a public key, and wherein the digital signature is applied to the software update by an issuer of the software update using a private key corresponding to the authentication key. [15] Vehicle system (100) according to claim 11, wherein the telematics control unit (104) is further configured to to determine an updated version of the software update before it is received; to determine a current version of software that is currently installed in the electronic control unit (114); to compare the updated version with the current version to obtain a comparison result; and to decide, based on the comparison result, whether to receive the software update. [16] Vehicle system (100) according to claim 11, wherein the telematics control unit (104) is further configured to reject the software update in response to the fact that an update version of the software is incompatible with a current version of the software installed in the electronic control unit (114). [17] Vehicle system (100) according to claim 11, wherein the wireless network (214) is at least one of a mobile network, a WLAN network or a Bluetooth network. [18] Device for overwriting with software an electronic control unit (114) of a vehicle, comprising: a connection unit (108) configured to couple the device of an in-vehicle network (102) of the vehicle; a memory configured to store a software update for an electronic control unit (114); and a processor that is configured to to initiate a programming process for the electronic control unit (114) via the connection unit (108); to authenticate the software update using an authentication key in order to obtain an authentication result; and If the authentication result indicates successful authentication, send the software update via the vehicle's internal network (102) to the electronic control unit (114) to induce the electronic control unit (114) to perform the overwrite with the software update. [19] Device according to claim 18, further comprising a communication device configured to download the software update. [20] Device according to claim 18, wherein the processor is further configured to authenticate a digital signature of the software update using the authentication key, wherein the authentication key is a public key, and wherein the digital signature is applied to the software update by an issuer of the software update using a private key corresponding to the authentication key. [21] Device according to claim 18, wherein the processor is further configured to determine to obtain the authentication key from the electronic control unit (114) in response to a determination that a version of the ECU software update is more extensive than a current version of the software installed on the electronic control unit (114).

Images