DIAGNOSTIC OVER IP AUTHENTICATION

A system comprises a computer including a processor and a memory, the memory including instructions such that the processor is programmed to: receive a data frame including data representing a unified diagnostic services (UDS) request, wherein the data frame includes a hash value and a cipher-based message authentication code (CMAC); calculate an authentication CMAC based on the hash value; compare the CMAC with the authentication CMAC; and transmit control data to a communication module when the CMAC matches the authentication CMAC.

BACKGROUND

The number and types of electronic devices within vehicles have increased significantly with the digitalization of vehicle parts. Generally, electronic devices may be used throughout the vehicle, such as in a power train control system, a body control system, a chassis control system, a vehicle network, a multimedia system, and so forth. In some instances, diagnostic devices transmit diagnostic requests to the electronic devices for diagnostic purposes.

DETAILED DESCRIPTION

A system comprises a computer including a processor and a memory, the memory including instructions such that the processor is programmed to: receive a data frame including data representing a unified diagnostic services (UDS) request, wherein the data frame includes a hash value and a cipher-based message authentication code (CMAC); calculate an authentication CMAC based on the hash value; compare the CMAC with the authentication CMAC; and transmit control data to a communication module when the CMAC matches the authentication CMAC.

In other features, the processor is further programmed to: calculate an integrity hash value based on the UDS request; and compare the hash value with the integrity hash value.

In other features, the processor is further programmed to: ignore the UDS request when at least one of the CMAC does not match the authentication CMAC or the hash value does not match the integrity hash value.

In other features, the processor is further programmed to: process the UDS request when the CMAC matches the authentication CMAC and the hash value matches the integrity hash value.

In other features, the processor is further programmed to: transmit diagnostic data based on the UDS request.

In other features, the data frame is received via a vehicle bus.

A system comprising: a communication module comprising a computer including a processor and a memory, the memory including instructions such that the processor is programmed to: calculate a hash value based on a UDS request; calculate a CMAC based on the hash value; encapsulate the UDS request, the hash value, and the CMAC into a data frame; and transmit the data frame to a vehicle computer; the vehicle computer comprising a computer including a processor and a memory, the memory including instructions such that the processor is programmed to: receive the data frame; calculate an authentication CMAC based on the hash value; compare the CMAC with the authentication CMAC; and transmit control data to the communication module when the CMAC matches the authentication CMAC.

In other features, the processor of the vehicle computer is further programmed to: calculate an integrity hash value based on the UDS request; and compare the hash value with the integrity hash value.

In other features, the processor of the vehicle computer is further programmed to: ignore the UDS request when at least one of the CMAC does not match the authentication CMAC or the hash value does not match the integrity hash value.

In other features, the processor of the vehicle computer is further programmed to: process the UDS request when the CMAC matches the authentication CMAC and the hash value matches the integrity hash value.

In other features, the processor of the vehicle computer is further programmed to: transmit diagnostic data based on the UDS request.

In other features, the processor of the communication module is further programmed to: receive a data packet including the UDS request.

In other features, the processor of the communication module is further programmed to: extract the UDS request from the data packet.

In other features, the data frame is transmitted to the vehicle computer via a vehicle bus.

A method comprises: receiving a data frame including data representing a unified diagnostic services (UDS) request, wherein the data frame includes a hash value and a cipher-based message authentication code (CMAC); calculating an authentication CMAC based on the hash value; comparing the CMAC with the authentication CMAC; and transmitting control data to a communication module when the CMAC matches the authentication CMAC.

In other features, the method further comprises: calculating an integrity hash value based on the UDS request; and comparing the hash value with the integrity hash value.

In other features, the method further comprises: ignoring the UDS request when at least one of the CMAC does not match the authentication CMAC or the hash value does not match the integrity hash value.

In other features, the method further comprises: processing the UDS request when the CMAC matches the authentication CMAC and the hash value matches the integrity hash value.

In other features, the method further comprises: transmitting diagnostic data based on the UDS request.

In other features, the method further comprises: receiving the data frame via a vehicle bus.

Diagnostic over Internet Protocol (DoIP) is an automotive diagnostics protocol that facilitates diagnostics related communication between external test equipment and electronic controller units (ECUs) within a vehicle. DoIP enables access to a vehicle's various electronic components, such as the ECUs, through a Ethernet or cellular connection, such that physical access to the vehicle is not required.

DoIP utilizes a Unified Diagnostic Services (UDS) protocol to allow for the transmission of payloads between the external test equipment and the various electronic components of the vehicle. UDS is specified by the International Organization for Standardization as ISO 14229-1. By using the UDS protocol, the payloads can be transmitted between the test equipment and the electronic components over a vehicle's bus, such as a controller area network (CAN). The present disclosure discloses a system and a method for authenticating a UDS request to mitigate unauthorized execution of diagnostic commands and/or extraction of diagnostic information from the vehicle. As discussed in greater detail herein, an ECU can authenticate a UDS request using a single dataframe, which typically provides an increase in vehicle bus efficiency over existing techniques. Thus, ECU authentication of a UDS request using a single dataframe as disclosed herein can provide the advantage of consuming less bandwidth on a vehicle data bus, providing the bandwidth for other vehicle operations and communications and/or allowing for more responsive communications on the vehicle communication bus, for example.

FIG. 1is a block diagram of an example vehicle system100. The system100includes a vehicle105, which is a land vehicle such as a car, truck, etc. The vehicle105includes a computer110, vehicle sensors115, actuators120to actuate various vehicle components125, and a vehicle communications module130. Via a network135, the communications module130allows the computer110to communicate with a server145.

The computer110includes a processor and a memory. The memory includes one or more forms of computer-readable media, and stores instructions executable by the computer110for performing various operations, including as disclosed herein.

The computer110may operate a vehicle105in an autonomous, a semi-autonomous mode, or a non-autonomous (manual) mode. For purposes of this disclosure, an autonomous mode is defined as one in which each of vehicle105propulsion, braking, and steering are controlled by the computer110; in a semi-autonomous mode the computer110controls one or two of vehicles105propulsion, braking, and steering; in a non-autonomous mode a human operator controls each of vehicle105propulsion, braking, and steering.

The computer110may include programming to operate one or more of vehicle105brakes, propulsion (e.g., control of acceleration in the vehicle by controlling one or more of an internal combustion engine, electric motor, hybrid engine, etc.), steering, climate control, interior and/or exterior lights, etc., as well as to determine whether and when the computer110, as opposed to a human operator, is to control such operations. Additionally, the computer110may be programmed to determine whether and when a human operator is to control such operations.

The computer110may include or be communicatively coupled to, e.g., via the vehicle105communications module130as described further below, more than one processor, e.g., included in electronic controller units (ECUs) or the like included in the vehicle105for monitoring and/or controlling various vehicle components125, e.g., a powertrain controller, a brake controller, a steering controller, etc. Further, the computer110may communicate, via the vehicle105communications module130, with a navigation system that uses the Global Position System (GPS). As an example, the computer110may request and receive location data of the vehicle105. The location data may be in a conventional form, e.g., geo-coordinates (latitudinal and longitudinal coordinates).

The computer110is generally arranged for communications on the vehicle105communications module130and also with a vehicle105internal wired and/or wireless network, e.g., a bus or the like in the vehicle105such as a controller area network (CAN) or the like, and/or other wired and/or wireless mechanisms.

Via the vehicle105communications network, the computer110may transmit messages to various devices in the vehicle105and/or receive messages from the various devices, e.g., vehicle sensors115, actuators120, vehicle components125, a human machine interface (HMI), etc. Alternatively or additionally, in cases where the computer110actually comprises a plurality of devices, the vehicle105communications network may be used for communications between devices represented as the computer110in this disclosure. Further, as mentioned below, various controllers and/or vehicle sensors115may provide data to the computer110.

Vehicle sensors115may include a variety of devices such as are known to provide data to the computer110. For example, the vehicle sensors115may include Light Detection and Ranging (lidar) sensor(s)115, etc., disposed on a top of the vehicle105, behind a vehicle105front windshield, around the vehicle105, etc., that provide relative locations, sizes, and shapes of objects and/or conditions surrounding the vehicle105. As another example, one or more radar sensors115fixed to vehicle105bumpers may provide data to provide and range velocity of objects (possibly including second vehicles), etc., relative to the location of the vehicle105. The vehicle sensors115may further include camera sensor(s)115, e.g. front view, side view, rear view, etc., providing images from a field of view inside and/or outside the vehicle105.

The vehicle105actuators120are implemented via circuits, chips, motors, or other electronic and or mechanical components that can actuate various vehicle subsystems in accordance with appropriate control signals as is known. The actuators120may be used to control components125, including braking, acceleration, and steering of a vehicle105.

In the context of the present disclosure, a vehicle component125is one or more hardware components adapted to perform a mechanical or electro-mechanical function or operation—such as moving the vehicle105, slowing or stopping the vehicle105, steering the vehicle105, etc. Non-limiting examples of components125include a propulsion component (that includes, e.g., an internal combustion engine and/or an electric motor, etc.), a transmission component, a steering component (e.g., that may include one or more of a steering wheel, a steering rack, etc.), a brake component (as described below), a park assist component, an adaptive cruise control component, an adaptive steering component, a movable seat, etc.

In addition, the computer110may be configured for communicating via a vehicle-to-vehicle communication module or interface130with devices outside of the vehicle105, e.g., through a vehicle-to-vehicle (V2V) or vehicle-to-infrastructure (V2X) wireless communications to another vehicle, to (typically via the network135) a remote server145. The module130could include one or more mechanisms by which the computer110may communicate, including any desired combination of wireless (e.g., cellular, wireless, satellite, microwave and radio frequency) communication mechanisms and any desired network topology (or topologies when a plurality of communication mechanisms are utilized). Exemplary communications provided via the module130include cellular, Bluetooth®, IEEE 802.11, dedicated short range communications (DSRC), and/or wide area networks (WAN), including the Internet, providing data communication services.

The network135can be one or more of various wired or wireless communication mechanisms, including any desired combination of wired (e.g., cable and fiber) and/or wireless (e.g., cellular, wireless, satellite, microwave, and radio frequency) communication mechanisms and any desired network topology (or topologies when multiple communication mechanisms are utilized). Exemplary communication networks include wireless communication networks (e.g., using Bluetooth, Bluetooth Low Energy (BLE), IEEE 802.11, vehicle-to-vehicle (V2V) such as Dedicated Short-Range Communications (DSRC), etc.), local area networks (LAN) and/or wide area networks (WAN), including the Internet, providing data communication services.

A computer110can receive and analyze data from sensors115substantially continuously, periodically, and/or when instructed by a server145, etc. Further, object classification or identification techniques can be used, e.g., in a computer110based on lidar sensor115, camera sensor115, etc., data, to identify a type of object, e.g., vehicle, person, rock, pothole, bicycle, motorcycle, etc., as well as physical features of objects.

FIG. 2is a block diagram of an example server145. The server145includes a computer235and a communications module240. The computer235includes a processor and a memory. The memory includes one or more forms of computer-readable media, and stores instructions executable by the computer235for performing various operations, including as disclosed herein. The communications module240allows the computer235to communicate with other devices, such as the vehicle105, e.g., via the network135according to conventional wireless and/or wired communication protocols.

FIG. 3illustrates an example environment300for authenticating Unified Diagnostic Services (UDS) requests transmitted over the communication network135. In the environment300illustrated, the communication network135comprises a wireless network. The environment300can include the server145that communicates with the vehicle105via the communication module130. The communication module130includes a processor and a memory. The memory includes one or more forms of computer-readable media, and stores instructions executable by the communication module130for performing various operations, including as disclosed herein.

The server145can be a diagnostic device that transmits UDS requests to the communication module130via the network135and can receive diagnostic data from the vehicle105based on the UDS requests. The communication module130can comprise an in-vehicle gateway that provides scheduling and protocol conversion. For example, the communication module130can receive data packets encoded according to a Transmission Control Protocol/Internet Protocol (TCP/IP) and can decapsulate the received data packets and transmit the decapsulated data to the computer110via one or more vehicle buses305, e.g., CAN.

The communication module130and/or the server145can establish a session to transmit and/or receive data packets between the communication module130and/or the server145. The session can be established upon a determination that diagnostic data is to be transmitted from the computer110to the server145. In an example implementation, the session can be established between the server145and the communication module130according to a Transport Layer Security (TLS) protocol. In another example implementation, the session can be established between the server145and the communication module130according to a Service 0×29 Authentication request as specified in the UDS standard.

Once the session is established, the server145can encode, i.e., encapsulate, one or more data packets that include a UDS request. The UDS request can comprise a diagnostic message for the computer110. As discussed above, the vehicle105can include multiple computers110that comprise ECUs for monitoring the vehicle105components125. In an example implementation, the diagnostic message can include a command to retrieve diagnostic data from the computer110, which is described in greater detail below. Additionally or alternatively, the computer110may causes one or more vehicle105components125to be actuated based on the UDS request. For example, a vehicle105component125can be actuated such that diagnostic data can be measured and transmitted in response to the UDS request. After receiving the one or more data packets from the server145, the communication module130can authenticate the one or more data packets as discussed herein. The communication module130decapsulates the received data packet(s) and verifies a current quality of service (QoS) threshold with the computer110, e.g., sending a QoS request to the computer110. The QoS threshold can be included within the UDS request and can be defined as characteristic of a data link connection between the communication module130and the computer110. If the communication module130determines that the QoS threshold of the UDS request is above a QoS threshold of the computer110, the communication module130and the computer110can use conventional QoS negotiation techniques to determine a QoS threshold.

The communication module130can calculate a hash value for the UDS request. The hash value can be defined as a numeric value of fixed length that uniquely identifies the data of the UDS request. The communication module130can use any conventional hash functions that map the data of the UDS request to the fixed length numeric value. Once the communication module130calculates the hash value of the UDS request, the communication module130calculates one or more message authentication codes (MACs) based on the hash value. In an example implementation, the communication module130can use conventional cipher-based message authentication code (CMAC) techniques, which are described, for example, in NIST (The National Institute of Standards and Technology) special publication 800-38B, May 2005.

For example, a secret key is used to encrypt and decrypt the hash value, and the secret key can be stored in the communication module130and a copy of the secret key can be stored in the computer110. The communication module130can use the secret key to encrypt the hash value into ciphertext, e.g., encrypted ciphertext, and the computer110can use the secret key to decrypt the ciphertext. For example, the communication module130uses a CMAC algorithm to generate a CMAC. The communication module130can generate the CMAC by inputting the secret key and the hash value into a CMAC algorithm and can append the hash value and the CMAC to the UDS request as discussed below.

FIG. 4illustrates an example data frame400generated by the communication module130. As shown, the data frame400includes a destination address portion405, a control data portion410, a message length portion415, a data portion420, a hash value portion425, and a CMAC portion430. The destination address portion405can include a destination address for the data frame400, e.g., the computer110, and the control data portion410can include control data. The message length portion415can include a length, e.g., number of bits, in the data portion420, and the data portion420can include the UDS request. The hash value portion425can include the hash value generated by the communication module130, and the CMAC portion430can include the CMAC generated by the communication module130. The data frame400can be transmitted to the computer110via the vehicle105bus305after the data frame400is encapsulated by the communication module130. In some implementations, the communication module130transmits the data frame400including a first data frame of the UDS request.

The computer110can attempt to authenticate the data frame400using the copy of the secret key after receiving the data frame400. In an example implementation, the computer110can decapsulate the data frame400to obtain the hash value portion425and the CMAC portion430. The computer110can generate an authentication CMAC by inputting the copy of the secret key and the hash value into a CMAC algorithm stored on the computer110. The computer110compares the authentication CMAC with the CMAC obtained from the CMC portion430. The computer110can authenticate the data frame400when the authentication CMAC matches the CMAC portion430. The computer110can authenticate a UDS request using a single data frame400, e.g., based on the CMAC included in the data frame400, which typically results in an increase in bus305bandwidth since additional non-authenticated data frames are not transmitted if an initial data frame400is not authenticated.

After the data frame400is authenticated, the computer110transmits the control data from the control data portion410to the communication module130to indicate the data frame has been authenticated. After receiving the control data, the communication module130transmits the remaining data frames including data representing the UDS request to the computer110. If the data frame400is not authenticated, the computer110ignores the UDS request.

After the remaining data frames of the UDS request have been received at the computer110, the computer110calculates an integrity hash value for the UDS request and compares the integrity hash value to the hash value from the hash value portion425. The computer110can use the hash value function used by the communication module130to calculate the integrity hash value. If the integrity hash value matches the hash value, the computer110transmits an acknowledgement to the communication module130and performs actions requested in the UDS request. If the integrity hash value does not match the hash value, the computer110ignores the UDS request.

FIG. 5illustrates an example process500for processing a UDS request. Blocks of the process500can be executed by a processor of the communication module130. The process500begins at block505in which a determination is made whether data, e.g., a UDS request, has been received from the server145. The communication module130can monitor whether a UDS request has been received from the server145via the communication network135. The UDS request can comprise a TCP/IP data packet. If a UDS request has not been received, the process500returns to block505. If a UDS request has been received from the server145, the communication module130extracts the UDS request and verifies the QoS threshold with a destination computer110at block510. In some implementations, the communication module130and the computer110can use conventional QoS negotiation techniques to determine a QoS threshold if the QoS threshold of the UDS request is above a QoS threshold of the computer110.

At block515, the communication module130calculates a hash value for the UDS request, e.g., payload. At block520, the communication module130calculates a CMAC based on the hash value. At block525, the communication module130transmits a data frame, such as data frame400, to the destination computer110. As discussed above, the communication module130generates and transmits a data unit400that includes data representing the UDS request, the hash value, and the CMAC.

At block530, the communication module130determines whether control data has been received within a predefined time period. The predefined time period can be defined as a timeout period set by the vehicle105manufacturer. If control data is not received within the predefined time period, the process500ends. If control data has been received within the predefined time period, the communication module130transmits one or more data frames, e.g., the remaining data frames including the UDS request, to the computer110at block535. The one or more data frames can include data representing the UDS request. In an example implementation, the one or more data frames transmitted at block535do not include data representing the CMAC. At block540, the communication module130terminates a session after an acknowledgement is received. The process500then ends.

FIG. 6illustrates an example process600for authenticating a UDS request. Blocks of the process600can be executed by a processor of the computer110. The process600begins at block605in which a determination is made whether a data frame, such as a data frame400has been received from the communication module130. If the data frame has not been received, the process600returns to block605. If the data frame has been received, the computer110decapsulates the data frame to obtain the hash value and the CMAC at block610.

At block615, the computer110calculates an authentication CMAC using the hash value, as described in greater detail above. At block620, the computer110determines whether the authentication CMAC matches the CMAC obtained from the data frame. If the authentication CMAC does not match the CMAC, the computer110ignores the data frame, and the process600ends. If the CMAC matches the CMAC, the computer110transmits control data the communication module130at block625. At block630, the computer110receives the remaining data frames and calculates an integrity hash value using the data from each of the data frames representing the UDS request.

At block635, the computer110determines whether the integrity hash value matches the hash value obtained from the data frame. If the integrity hash value does not match the hash value, the computer110ignores the UDS request, and the process600ends. If the verification hash value matches the hash value, the computer110verifies the UDS request and transmits an acknowledgement to the communication module130at block640. At block645, the computer110processes the UDS request. In an example implementation, the computer110may cause one or more vehicle105components125to be actuated based on the UDS request such that diagnostic data can be measured and transmitted in response to the UDS request. For example, the computer110can transmit diagnostic data according to the UDS request. The process600then ends.

With regard to the media, processes, systems, methods, heuristics, etc. described herein, it should be understood that, although the steps of such processes, etc. have been described as occurring according to a certain ordered sequence, such processes may be practiced with the described steps performed in an order other than the order described herein. It further should be understood that certain steps may be performed simultaneously, that other steps may be added, or that certain steps described herein may be omitted. In other words, the descriptions of processes herein are provided for the purpose of illustrating certain embodiments, and should in no way be construed so as to limit the claims.