End-to-end vehicle secure ECU unlock in a semi-offline environment

Method and apparatus are disclosed for end-to-end vehicle secure ECU unlock in a semi-offline environment. An example vehicle electronic control unit includes a first processor and a second processor. The first processor, when unlocked, provides diagnostic information. The second processor sends a seed value to a diagnostic tool. Additionally, the second processor, in response to receiving a second key, unlocks the first processor. The second processor, after receiving a first verifier, decrypts the first verifier to generate a new key, replaces a current key with the new key, and sends a second verifier to the diagnostic tool.

TECHNICAL FIELD

The present disclosure generally relates to diagnostic tools for electronic control units (ECUs) of a vehicle and, more specifically, end-to-end vehicle secure ECU unlock in a semi-offline environment.

BACKGROUND

Modern vehicles contain electronic control units (ECUs) that are capable of performing on-board diagnostic (OBD) processes. Vehicles include connectors, such as OBD-II connectors, that allow external diagnostic tools to be coupled to the vehicle data buses to interact with ECUs. A diagnostic tool may query a vehicle for OBD test results as well as for real-time data. Moreover, a diagnostic tool may direct an ECU to perform some action. For example, a vehicle repair facility may connect to the OBD-II port to obtain information to determine why a check-engine light is illuminated. Some ECUs, such as the powertrain control module, perform critical functions. As such, those ECUs are secured to prevent accessing the diagnostic capability without authorization.

SUMMARY

Example embodiments are disclosed for end-to-end vehicle secure ECU unlock in a semi-offline environment. An example vehicle electronic control unit includes a first processor and a second processor. The first processor, when unlocked, provides diagnostic information. The second processor sends a seed value to a diagnostic tool based on a first key. Additionally, the second processor, in response to receiving a second key, unlocks the first processor. The second processor, after receiving a first verifier, decrypts the first verifier to generate a third key, replaces the first key with the third key, and sends a second verifier to the diagnostic tool.

A secure processor sends a random seed to a diagnostic tool. In response to receiving an unlock key, the secure processor unlocks a diagnostic processor. The diagnostic processor exchanges the diagnostic information with the diagnostic tool. After receiving a first verifier, the secure processor decrypts the first verifier to generate an new offline key. The secure processor replaces an initial offline key with the new offline key. Additionally, the secure processor sends second verifier to the diagnostic tool.

An example system includes a remote ECU security manager (ESM), a diagnostic tool, and a vehicle electronic control unit. The remote security manager provides a first offline key, a first verifier, and a second verifier to a diagnostic tool, and, in response to receiving a completion notification from the diagnostic tool, replaces the first offline key stored in memory with a second offline key. The diagnostic tool generates an unlock key based on the first offline key and a random seed value from a vehicle electronic control unit. In response to receiving a success notification, the diagnostic tool exchanges diagnostic information with the vehicle electronic control unit and sends the first verifier to the vehicle electronic control unit. The vehicle electronic control unit sends the seed value to the diagnostic tool, unlocks a diagnostic mode in response to the unlock key from the diagnostic tool being valid, generates the second offline key based on the first verifier, and replaces the first offline key with the second offline key.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

End-to-end secure electronic control units (ECUs) utilize different levels of security protection when the vehicle is serviced. As used herein, an “end-to-end secure ECU” refers to an ECU with diagnostic routines that are only accessible after authentication and authorization from a remote (e.g., accessible via a network connection) server operated by an ECU security manager (ESM) (e.g., an ECU manufacture, a vehicle manufacturer, a third party key holder, etc.). Traditionally, end-to-end security requires online communication (e.g., via an Ethernet, a wireless local area network, a cellular and/or a satellite connection, etc.) between the end-to-end secure ECU and the ESM. Such end-to-end secure ECUs include a generated seed value, an unlock key, and a security key. When a diagnostic tool is connected to an on-board diagnostic port (e.g., the OBD-II port, etc.) of the vehicle, the end-to-end secure ECU provides the seed value to the ESM via the network connection. The ESM also includes the security key. The ESM uses the seed value and the security key to generate a candidate unlock key. The ESM sends the candidate unlock key to the ECU via the network connection. When the candidate unlock key matches the unlock key of the end-to-end secure ECU, the end-to-end secure ECU unlocks and allows the diagnostic tool to access the diagnostic processes of the ECU.

However, in some scenarios, the diagnostic tool cannot maintain a continuous connection to a network. As used herein, “online” refers to the diagnostic tool being connected to the ESM via a network connection. Additionally, “offline” refers to the diagnostic tool not being connected to the ESM via a network connection. “Semi-offline” refers to the diagnostic tool having intermittent access to the ESM via a network connection. For example, initially, a vehicle may be brought into a repair garage to be diagnosed where a network connection is available. In such an example, to diagnose the vehicle, a technician may perform a road test and exit the repair garage where the network connection is not available. In such an example, the technician may, via the diagnostic tool, need to access the diagnostic processes of the ECU while the diagnostic tool is not connected to the network.

As disclosed below, the end-to-end security system provides a method to access the diagnostic processes of an end-to-end secure ECU when the diagnostic tool is semi-offline. The end-to-end secure ECU and the ESM share a security key (SKEY), an offline key (OKEY), and a counter value. Initially, the diagnostic tool requests the offline key (OKEY) from the ESM while the diagnostic tool is online. The ESM has a current offline key (OKEY) in memory, and OKEY is unique to the ECU instance and the vehicle instance under test. In response to receiving a request from the diagnostic tool, the ESM generates a new offline key (OKEY) and at least two verifiers (V1and V2). The verifiers (V1and V2) are based on the shared security key (SKEY), the counter value, and/or the key offline key (OKEY). The ESM provides the current offline key (OKEY) and the verifiers (V1and V2) to the diagnostic tool.

When offline, the diagnostic tool requests access to the end-to-end secure ECU. The end-to-end secure ECU provides a seed value to the diagnostic tool. Using the seed value and the current offline key (OKEY), the diagnostic tool generates a candidate unlock key (UKEY) and sends it to the end-to-end secure ECU. The end-to-end secure ECU generated the unlock key (UKEY) based on the seed value sent to the diagnostic tool and the current offline key (OKEY) stored in secure memory. In response to the candidate unlock key (UKEY) matching the unlock key (UKEY) generated by the end-to-end secure ECU, the end-to-end secure ECU unlocks access to its diagnostic functions and notifies the diagnostic tool. The end-to-end secure ECU and diagnostic tool then can exchange diagnostic information. When the diagnostic is complete, the diagnostic tool sends a first verifier (V1) to the end-to-end secure ECU. The end-to-end secure ECU then generates (a) a new offline key based on the first verifier (V1) using the shared security key (SKEY), and (b) a candidate verifier (V2_C) based on the new offline key (OKEY) and the shared counter value. The end-to-end secure ECU sends the candidate verifier (V2_C) to the diagnostic tool. When the diagnostic tool is online, in response to the candidate verifier (V2_C) matching the second verifier (V2) from the ESM, the diagnostic tool notifies the ESM. The ESM then sets the new offline key (OKEY) to be the current offline key (OKEY).

In such a manner, a malicious third party is unable to access the diagnostic functions of the end-to-end secure ECU without knowing the offline key (OKEY). Additionally, because the offline key (OKEY) changes after every diagnostic session, the malicious third party is unable to update the offline key (OKEY) without knowing the security key (SKEY). As a result, even if the malicious third party is able to intercept the current offline key (OKEY), they can only access the diagnostic processes once.

FIG. 1illustrates a vehicle100with secured electronic control units (ECUs)102and104in accordance with the teachings of this disclosure. The vehicle100may be a standard gasoline powered vehicle, a hybrid vehicle, an electric vehicle, a fuel cell vehicle, and/or any other mobility implement type of vehicle. The vehicle100includes parts related to mobility, such as a powertrain with an engine, a transmission, a suspension, a driveshaft, and/or wheels, etc. The vehicle100may be non-autonomous, semi-autonomous (e.g., some routine motive functions controlled by the vehicle100), or autonomous (e.g., motive functions are controlled by the vehicle100without direct driver input). In the illustrated example the vehicle includes an on-board diagnostic port106(e.g., an OBD-II port, etc.) communicably connected to the secure ECUs102and104via vehicle data buses108.

The on-board diagnostic port106is a connector configured to receive a mating connector110communicatively coupled to a diagnostic tool112. In some examples, the on-board diagnostic port106is implemented in accordance with the On-Board Diagnostic II (OBD-II) specification (e.g., SAE J1962 and SAE J1850) maintained by the Society of Automotive Engineers (SAE). In some examples, the on-board diagnostic port106is under or near an instrument panel cluster of the vehicle100. In some examples, the OBD-II port is a wireless radio serving to wirelessly connect the vehicle100with the diagnostic tool112.

The ECUs102and104monitor and control the subsystems of the vehicle100. The ECUs102and104communicate and exchange information via the vehicle data buses108. Additionally, the ECUs102and104communicate properties (such as status, sensor readings, control state, error and diagnostic codes, etc.) to and/or receive requests from other ECUs102and104and/or the diagnostic tool112via the mating connector110connected to the on-board diagnostic port106. Some vehicles100may have seventy or more ECUs102and104located in various locations around the vehicle100. The ECUs102and104are discrete sets of electronics that include their own circuit(s) (such as integrated circuits, microprocessors, memory, storage, etc.) and firmware, sensors, actuators, and/or mounting hardware. For example, the ECUs102and104may include a body control module, a powertrain control module, a brake control module, and/or a telematics control unit, etc.

The ECUs102and104have different modes of operation, such as a normal mode and a diagnostic mode. While the vehicle100is operating, the ECUs102and104are in the normal mode by default. While in the normal mode, the ECUs102and104perform functions for the operation of the vehicle100, but sensitive functions are not accessible. In diagnostic mode, the ECUs102and104may, for example, (a) report status and sensor information, (b) be rebooted, (c) be reprogrammed, (d) be commanded by the diagnostic tool112to perform certain actions and/or (e) test connections to the related subsystems, etc. For example, a body control module may report the status of the headlights, be commanded by the diagnostic tool112to test the headlights (e.g., cause the headlights cycle in a specific pattern), and/or reset (which may cause the headlights to turn off while the body control module reboots.). The diagnostic tool112sends commands to the ECUs102and104to enter the diagnostic mode in order to test and/or diagnose the ECU(s)102and104.

Some ECUs102and104are secured. When the ECU(s)102and104are secured, the ECU(s)102and104do not enter the diagnostic mode unless the diagnostic tool112is authorized. As disclosed below inFIGS. 2 and 3A, 3B, the diagnostic tool112is authorized when it provides a correct unlock key (UKEY) to the secured ECU(s)102and104.

The ECUs102include an operations processor or controller114, a secure processor or controller116(sometimes referred to as a “cryptoprocessor”), and memory118. The operations processor or controller114controls the operation of the ECUs102and104. The operations processor or controller114may be any suitable processing device or set of processing devices such as, but not limited to: a microprocessor, a microcontroller-based platform, a suitable integrated circuit, one or more field programmable gate arrays (FPGAs), and/or one or more application-specific integrated circuits (ASICs). Additionally, the secure processor or controller116may be any suitable processing device or set of processing devices such as, but not limited to: a microprocessor, a microcontroller-based platform, an integrated circuit, one or more FPGAs, and/or one or more ASICs. The secure processor or controller116is a dedicated processor and/or circuit to perform cryptographic operations associated with determining whether a diagnostic tool112is authorized to access the diagnostic mode of the ECU102. In some examples, the secure processor or controller116includes physical security measures to resist physical tampering. In some examples, the ECU(s)104does not include the secure processor or controller116. In such examples, the cryptographic operations associated with determining whether a diagnostic tool112is authorized are performed by the operations processor or controller114.

The memory118may be volatile memory (e.g., RAM, which can include non-volatile RAM, magnetic RAM, ferroelectric RAM, and any other suitable forms); non-volatile memory (e.g., disk memory, FLASH memory, EPROMs, EEPROMs, memristor-based non-volatile solid-state memory, etc.), unalterable memory (e.g., EPROMs), read-only memory, and/or high-capacity storage devices (e.g., hard drives, solid state drives, etc). In some examples, the memory118includes multiple kinds of memory, particularly volatile memory and non-volatile memory. In some examples, the memory118includes secure memory communicatively coupled to the secure processor or controller116via a secure data bus. The secure portion of the memory118includes an embedded hardware encryption engine with its own authentication keys to securely store information. The cryptographic algorithm of the hardware encryption engine encrypts (a) data stored in the secure portion of the memory118and (b) data sent between the secure portion of the memory118and the secure processor or controller116.

The memory118is computer readable media on which one or more sets of instructions, such as the software for operating the methods of the present disclosure can be embedded. The instructions may embody one or more of the methods or logic as described herein. In a particular embodiment, the instructions may reside completely, or at least partially, within any one or more of the memory118, the computer readable medium, and/or within the processors114and116during execution of the instructions.

The vehicle data bus(es)108communicatively couple(s) the ECUs102and104and the on-board diagnostic port106. The vehicle data bus(es)108may be implemented in accordance with a controller area network (CAN) bus protocol as defined by International Standards Organization (ISO) 11898-1, a Media Oriented Systems Transport (MOST) bus protocol, a CAN flexible data (CAN-FD) bus protocol (ISO 11898-7) and/a K-line bus protocol (ISO 9141 and ISO 14230-1), and/or an Ethernet™ bus protocol IEEE 802.3 (2002 onwards), etc.

The diagnostic tool112communicates with the ECUs102and104via the mating connector110plugged into the on-board diagnostic port106. In the illustrated example, the diagnostic tool112is connected to the mating connector110via a wired connection. Alternatively, in some examples, the mating connector110and the diagnostic tool112include wireless controllers (e.g., a wireless local area network controller, a Bluetooth® controller, a Bluetooth® Low Energy controller (BLE), etc.). In such examples, the mating connector110and the diagnostic tool112are communicatively coupled via a wireless connection.

The diagnostic tool112has an online mode and an offline mode. In the online mode, the diagnostic tool112is communicatively coupled to an ECU security manager (ESM)120located on an external network. The diagnostic tool112includes a wired or wireless interface to communicatively couple with the ESM120. When in the online mode, the diagnostic tool112requests authentication data122for a particular vehicle100based on, for example, the vehicle identification number (VIN) of the vehicle100to be diagnosed. In some examples, the diagnostic tool112retrieves the VIN from the vehicle100to be diagnosed via the on-board diagnostic port106. Alternatively, in some example, a technician enters the VIN via an input interface (e.g., a keypad, a touch screen, etc.) of the diagnostic tool112. After receiving the authentication data122, the diagnostic tool112can exchange authentication tokens124and126with the ECU102and104to be diagnosed while in the online or the offline mode without further communicating with the ESM120.

To become authorized to diagnose the ECU(s)102and104, the diagnostic tool112sends an access request to the ECU(s)102and104to be diagnosed. The ECU(s)102and104respond with seed values124. Based on the authentication data122received from the ESM and the seed values124, the diagnostic tool112generates a candidate unlock key (UKEY)126. The diagnostic tool112sends the candidate unlock keys (UKEY)126to the ECU(s)102and104. In response to the candidate unlock keys (UKEY)126being correct, the ECU(s)102and104unlock and accept commands to enter their diagnostic mode. After being authorized, the diagnostic tool112sends diagnostic commands128to the ECUs102and104. For example, the diagnostic tool112may instruct one of the ECUs102and104to enter its diagnostic mode and perform a test routine. Additionally, the diagnostic tool112receives diagnostic data130from the ECUs102and104. When the diagnostic is complete and the diagnostic tool112is in the online mode, the diagnostic tool112sends completion data132to the ESM120.

In the illustrated example, the diagnostic tool112includes a processor134and memory136. The processor134may be any suitable processing device or set of processing devices such as, but not limited to: a microprocessor, a microcontroller-based platform, a suitable integrated circuit, one or more FPGAs, and/or one or more ASICs. The memory136may be volatile memory (e.g., RAM, which can include non-volatile RAM, magnetic RAM, ferroelectric RAM, and any other suitable forms); non-volatile memory (e.g., disk memory, FLASH memory, EPROMs, EEPROMs, memristor-based non-volatile solid-state memory, etc.), unalterable memory (e.g., EPROMs), read-only memory, and/or high-capacity storage devices (e.g., hard drives, solid state drives, etc). In some examples, the memory136includes multiple kinds of memory, particularly volatile memory and non-volatile memory.

The ESM120stores security keys (SKEY) and counter values for the ECUs102and104in association with vehicle identifiers (such as VINs, etc.) and/or with ECU identifiers (such as a serial number, etc.). As disclosed below inFIGS. 2 and 3A, 3B, in response to receiving a request with a vehicle identifier from a diagnostic tool112, the ESM120generates the authentication data122based on the security key (SKEY) and the counter value associated with the vehicle identifier. In some examples, to send the request, the diagnostic tool112first logs into the ESM120using separate credentials (e.g., a username and password, an exchange of authentication tokens, etc.). In response to receiving completion data132, the ESM120changes the authentication data122that will be sent in response to another request for the particular vehicle100and ECUs102and104.

FIG. 2depicts a diagram illustrating accessing the ECUs102and104ofFIG. 1when a diagnostic tool112is in a semi-offline environment. In the illustrated example, the ESM120and the ECU(s)102and104share a common security key (SKEY)202and a common counter value (C)204. In some examples, the ECU(s)102and104in the vehicle100do not share a common SKEY or a common counter value. In such examples, the diagnostic tool112requests access to the ECU(s)102and104on an individual basis. The security key (SKEY) and the counter value (C) are assigned during, for example, the manufacture of the vehicle100. When the diagnostic tool112is online and a vehicle100is to be diagnosed, the diagnostic tool112requests the authentication data122from the ESM120based on the vehicle identifier of the vehicle100. In response to the request, the ESM120generates a new offline key (OKEY_N), a first verifier (V1), and a second verifier (V2) based on a security key (SKEY)202and a counter value (C)204stored by the ESM120. The first verifier (V1), and the second verifier (V2) are generated in accordance with Equation (1) below.
V1=encrypt(PKEY,OKEY_N∥C)
V2=encrypt(OKEY_N,C)  Equation (1)

In Equation (1) above, the first verifier (V1) and the second verifier (V2) are encrypted with a symmetrical encryption algorithm. In some examples, the first verifier (V1) and the second verifier (V2) are encrypted with an Advanced Encryption Standard (AES) algorithm, such as AES-128, AES-256, etc. The first verifier (V1) is the new offline key (OKEY_N) and the counter value (C)204encrypted with the security key (SKEY)202. The second verifier (V2) is the counter value (C)204encrypted by the new offline key (OKEY_N). The ESM120returns a current offline key (OKEY_C)206, the first verifier (V1) and the second verifier (V2) in the authentication data122.

When the diagnostic tool112is to perform a diagnostic routine on one or more of the ECU(s)102and104of the vehicle100, the diagnostic tool112requests the seed values124from the ECU(s)102and104. The ECU102and104generate, via the processor114or the cryptoprocessor116, the seed value124and sends the seed value124to the diagnostic tool112. The diagnostic tool112generates a candidate unlock key (UKEY_C) in accordance with Equation (2) below.
UKEY_C=encrypt(OKEY_C,SEED)  Equation (2)
In Equation (2) above SEED is the seed value124. The candidate unlock key (UKEY_C) is the result of encrypting the seed value124with the current offline key (OKEY_C)206. The diagnostic tool112sends the generated candidate unlock key (UKEY_C) to the ECU(s)102and104. Other functions may be used in place of encrypt in Equation (2) to generate the candidate unlock key (UKEY_C) based on the current offline key (OKEY_C)206and the seed value124and may be identified by any name.

The ECU(s)102and104generate(s) the unlock key (UKEY) in accordance with Equation (2) above based on the seed value124and the current offline key (OKEY_C)206stored in memory (e.g., the secure portion of the memory118). The ECU(s)102and104compare(s) the candidate unlock key (UKEY_C) provided by the diagnostic tool112to the generated unlock key (UKEY). If the generated unlock key (UKEY) matches the candidate unlock key (UKEY_C) provided by the diagnostic tool112, the ECU(s)102and104unlock the diagnostic mode. The ECU(s)102and104then notify the diagnostic tool112that the ECU(s)102and104have been unlocked. The diagnostic tool112and the ECU(s)102and104exchange diagnostic messages128and diagnostic data130.

When the diagnostics are complete, the diagnostic tool112sends the first verifier (V1) to the ECU(s)102and104. In response to receiving the first verifier (V1), the ECU(s)102and104recover the new offline key (OKEY_N) and the counter value (C)204in accordance with Equation (3) below.
[OKEY_N,C]=decrypt(PKEY,V1)  Equation (3)
In Equation (3) above, the ECU(s)102and104decrypt the first verifier (V1) with the security key (SKEY) to recover the new offline key (OKEY_N) and the counter value (C)204. This sets the new offline key (OKEY_N) to be the current offline key (OKEY_C)206stored in memory. The ECU(s)102and104generate a candidate second verifier (V2_C) in accordance with Equation (4) below.
V2_C=encrypt(OKEY_N,C)  Equation (4)
In Equation 4 above, the ECU(s)102and104encrypt the counter value (C)204with the new offline key (OKEY_N) to generate the candidate second verifier (V2_C). The ECU(s)102and104send(s) the candidate second verifier (V2_C) to the diagnostic tool112.

The diagnostic tool112compares the candidate second verifier (V2_C) received from the ECU(s)102and104with the second verifier (V2) received from the ESM120. When the candidate second verifier (V2_C) and the second verifier (V2) match and the diagnostic tool112is in the online mode, the diagnostic tool112sends the completion data132with the candidate second verifier (V2_C) to the ESM120. After verifying that the candidate second verifier (V2_C) and the second verifier (V2) match, the ESM120sets the new offline key (OKEY_N) to be the current offline key (OKEY_C)206. In such a manner, the ESM120verifies that the ECU(s)102and104have updated the offline key before switching offline keys.

In some examples, for various reasons, the diagnostic tool112may not send the completion data132after returning to the online mode. In some such example, the diagnostic tool112is (a) disabled from communicating with another vehicle100until the completion data is sent and/or (b) prevented from receiving more authentication data122by the ESM120. In some examples, the diagnostic tool112sends the first verifier (V1) to the ECU(s)102and104(a) while the diagnostic tool112is in the online mode before sending the seed request, or (b) with the seed request. In some such examples, the ECU(s)102and104generate(s) and switch(es) to the new offline key (OKEY_N) (a) after a certain number of vehicle key cycles, (b) after a certain period of time, or (c) after verifying the same candidate unlock key (UKEY_C) a threshold number of times. In some examples, the ESM120switches to the new offline key (OKEY_N) after a period of time (e.g., six hours, twelve hours, etc.) after receiving the request for the authentication data from the diagnostic tool112.

In some examples, the ESM120, ECU(s)102and104, and diagnostic tool112architectures can be such that OKEY_N keys are generated by ECU(s)102and104and not by the ESM120. In such examples, during the first online phase, the diagnostic tool112requests an encrypted version of OKEY_N. In response to this request, the ECU(s)102and104generate OKEY_N, encrypt OKEY_N according to Equation (5) below, and send OKEY_N_E to the diagnostic tool112, which then transmits OKEY_N_E to the ESM120(e.g., during block304ofFIG. 3Abelow).
OKEY_N_E=encrypt(PKEY,OKEY_N)  Equation (5)
Upon receipt of the request, instead of generating a new offline key, the ESM120decrypts OKEY_N_E in accordance with Equation (6) below.
OKEY_N=decrypt(PKEY,OKEY_N_E)  Equation (6)
OKEY_N is then transmitted to the diagnostic tool112for use in block316. In this example, the ECU(s)102and104invalidate OKEY_N after certain threshold criteria are met (as discussed above). In this example, the ESM120neither stores nor generates OKEY_N.

FIGS. 3A and 3Bare flowcharts of a method to access the secured ECUs102and104ofFIG. 1when a diagnostic tool112is in a semi-offline environment. Initially, at block302(FIG. 3A), the diagnostic tool112retrieves or otherwise receives an identifier (ID). The identifier is the vehicle identifier of the vehicle100to be diagnosed and/or the ECU identifier of the ECU102and104to be diagnosed. At block304, the diagnostic tool112requests the current offline key (OKEY_C) from the ESM120. At block306, the ESM120generates the new offline key (OKEY_N) based on the counter value (C)204and the security key (SKEY)202. At block308, the ESM120generates the first and second verifiers (V1, V2) based on the security key (SKEY)202, the counter (C)204and/or the new offline key (OKEY_N). At block310, the ESM120sends the authentication data122which includes the first and second verifiers (V1, V2) and the current offline key (OKEY_C).

At block312, in response to receiving the authentication data122, the diagnostic tool112requests the seed value124from the ECU(s)102and104. At block314, the ECU(s)102and104send the seed value124to the diagnostic tool112. At block316, the diagnostic tool112generates the candidate unlock key (UKEY_C) based on the seed value and the current offline key (OKEY_C). At block318, the diagnostic tool112sends the candidate unlock key (UKEY_C) to the ECU(s)102and104. At block320, the ECU(s)102and104compute the unlock key (UKEY) based on the current offline key (OKEY_C) stored in memory and the seed value. At block322, the ECU(s)102and104determine whether the candidate unlock key (UKEY_C) sent by the diagnostic tool112at block318matches the unlock key (UKEY) computed at block322. In response to the candidate unlock key (UKEY_C) matching the unlock key (UKEY), the method continues at block324(FIG. 3B). Otherwise, in response to the candidate unlock key (UKEY_C) not matching the unlock key (UKEY), the method ends.

At block324, the ECU(s)102and104unlock their diagnostic modes. At block326, the ECU(s)102and104notify the diagnostic tool. At blocks328and330, the ECU(s)102and104and the diagnostic tool112exchange diagnostic commands128and diagnostic data130until the diagnostic procedure is complete. At block332, the diagnostic tool112sends the first verifier (V1) to the ECU(s)102and104. At block334, the ECU(s)102and104recover the new offline key (OKEY_N) and the counter value (C) based on the first verifier (V1) and the security key (SKEY). At block336, the ECU(s)102and104set the new offline key (OKEY_N) to be the current offline key (OKEY_C). At block338, the ECU(s)102and104generate the second verifier (V2) based on the counter value (c) and the new offline key (OKEY_N) and sends the second verifier (V2) to the diagnostic tool112.

At block340, the diagnostic tool112compares the second verifier (V2) received from the ECU(s)102and104to the second verifier (V2) received from the ESM120. In response to the second verifier (V2) received from the ECU(s)102and104matching the second verifier (V2) received from the ESM120, the method continues at block342. Otherwise, in response to the second verifier (V2) received from the ECU(s)102and104not matching the second verifier (V2) received from the ESM120, the method continues at block346. At block342, the diagnostic tool112notifies the ESM120that the diagnostic service is complete. At block344, the ESM120sets the new offline key (OKEY_N) to be the current offline key (OKEY_C). At block346, the diagnostic tool112notifies the ESM120of the error.

The flowchart ofFIGS. 3A and 3Bare representative of machine readable instructions stored in memory (such as the memory118and136ofFIG. 1) that comprise programs that, when executed by a processor (such as the processors114,116, and134of FIG. a), implement the example ECU(s)102and104, the example diagnostic tool112, and the example ESM120ofFIGS. 1 and 2. Further, although the example program(s) is/are described with reference to the flowcharts illustrated inFIGS. 3A and 3B, many other methods of implementing the example ECU(s)102and104, the example diagnostic tool112, and the example ESM120may alternatively be used. For example, the order of execution of the blocks may be changed, and/or some of the blocks described may be changed, eliminated, or combined.