TRANSMISSION OF AUTHENTICATION KEYS

A vehicle system includes a first control module, a plurality of second control modules, and a vehicle network. The vehicle network communicatively couples the first control module and the second control modules. The first control module is programmed to generate an update command including a plurality of authentication keys and transmit the update command over the vehicle network. The update command is functionally addressed to be receivable by the second control modules. Each second control module is programmed to receive a configuration file; in response to receiving the update command, identify the authentication keys in the update command that are associated with that second control module based on the configuration file; and update with the identified authentication keys.

BACKGROUND

Symmetric-key algorithms are cryptographic algorithms using the same cryptographic keys for encrypting unencrypted data and for decrypting encrypted data. Symmetric-key algorithms can use stream ciphers or block ciphers. Stream ciphers encrypt characters of a message one by one. Block ciphers encrypt a block of bits while padding the plaintext. An example of block ciphering is the Advanced Encryption Standard algorithm promulgated by the National Institute of Standards and Technology.

DETAILED DESCRIPTION

Modern vehicles typically include several control modules that control various functions of the vehicle. The control modules can communicate with each other by sending messages through a vehicle network such as a Controller Area Network (CAN) bus. Communications between the control modules may be encrypted, e.g., using a symmetric-key algorithm. In a communication in which one of the control modules is a sender and one of the control modules is a receiver, the sender and the receiver may both have the same authentication key stored, which the sender uses to encrypt the communication and the receiver uses to decrypt the communication. The encryption can prevent the contents of the communication being known if the communication is intercepted. The control modules on board a vehicle may use several authentication keys, e.g., for respective functions or features of the vehicle. An authentication key for a particular function may be distributed to the control modules responsible for that function and not to other control modules. Each control module may have zero, one, or a few authentication keys depending on the functions for which that control module is responsible.

However, if a third party discovers one of the authentication keys, then the third party may be able to understand the contents of an intercepted communication. Thus, distributing the authentication keys must be done in a secure manner. An initial distribution of authentication keys can be performed at the time that the vehicle is manufactured. A subsequent distribution of authentication keys may occur, e.g., if control modules are repaired or replaced.

Described herein are techniques for distributing the authentication keys to the control modules in a manner that is both secure and quick. One of the control modules, referred to herein as the first control module, may be responsible for distributing the authentication keys to other control modules, referred to herein as the second control modules. The first control module is programmed to generate an update command including the authentication keys and transmit the update command over a vehicle network, e.g., the CAN bus. The update command is functionally addressed to be receivable by the second control modules. Functional addressing permits the update command to be sent to all the second control modules at once, rather than piecemeal with physically addressed commands sent individually to the second control modules. Each second control module is programmed to receive a configuration file; in response to receiving the update command, identify the authentication keys in the update command that are associated with that second control module based on the configuration file; and update with the identified authentication keys. The authentication keys are thereby transmitted more quickly, preventing a possible delay during the manufacturing process. The configuration files inform the second control modules which authentication keys the second control modules should use to update.

A vehicle system includes a first control module, a plurality of second control modules, and a vehicle network. The vehicle network communicatively couples the first control module and the second control modules. The first control module is programmed to generate an update command including a plurality of authentication keys and transmit the update command over the vehicle network, and the update command is functionally addressed to be receivable by the second control modules. Each second control module is programmed to receive a respective configuration file; in response to receiving the update command, identify the authentication keys in the update command that are associated with that second control module based on the respective configuration file; and update with the identified authentication keys.

In an example, the configuration files may indicate the authentication keys that are associated with the respective second control modules. In a further example, each configuration file may indicate the authentication keys that are associated with the respective second control module and may not indicate the authentication keys that are associated with others of the second control modules.

In another further example, the configuration files may list key identifiers for the authentication keys that are associated with the respective second control modules.

In an example, the update command may lack an association between the authentication keys and the second control modules.

In an example, more than one of the second control modules may be associated with one of the authentication keys.

In an example, the first control module may be further programmed to receive a transmission command, and transmit the update command in response to receiving the transmission command. In a further example, the first control module may be further programmed to validate the transmission command, and refrain from transmitting the update command until the transmission command is validated.

In another further example, the configuration files may be second configuration files, the first control module may be further programmed to receive a first configuration file, and after receiving the first configuration file, receive the transmission command.

In an example, the authentication keys in the update command may be encrypted. In a further example, the authentication keys in the update command may be differently encrypted from each other.

In an example, the update command may be receivable by a third control module that is not associated with any of the authentication keys in the update command.

In an example, the first control module may be further programmed to receive a plurality of verifications indicating that the second control modules received the update command. In a further example, the first control module may be further programmed to, upon failing to receive at least one of the verifications from at least one of the second control modules, retransmit the update command over the vehicle network.

In an example, the authentication keys may be symmetric encryption keys.

In an example, each second control module may be programmed to, in response to receiving the update command, transmit a verification to the first control module.

In an example, the second control modules may be programmed to encrypt messages with the authentication keys. In a further example, a first key of the authentication keys may be associated with a group of the second control modules, and each second control module in the group may be programmed to encrypt messages to others of the second control modules in the group with the first key.

In an example, each configuration file may indicate at least one group of the second control modules to which the respective second control module belongs, and the second control modules in each group may be associated with one of the authentication keys.

A method includes receiving a configuration file by a second control module; generating an update command including a plurality of authentication keys by a first control module; transmitting the update command over a vehicle network by the first control module; in response to receiving the update command, identifying the authentication keys in the update command that are associated with that second control module based on the configuration file by the second control module; and updating with the identified authentication keys by the second control module. The update command is functionally addressed to be receivable by a plurality of control modules including the second control module.

With reference to the Figures, wherein like numerals indicate like parts throughout the several views, a vehicle system105of a vehicle100includes a first control module110, a plurality of second control modules115, and a vehicle network120. The vehicle network120communicatively couples the first control module110and the second control modules115. The first control module110is programmed to generate an update command200including a plurality of authentication keys210and transmit the update command200over the vehicle network120. The update command200is functionally addressed to be receivable by the second control modules115. Each second control module115is programmed to receive a second configuration file; in response to receiving the update command200, identify the authentication keys210in the update command200that are associated with that second control module115based on the second configuration file; and update with the identified authentication keys210.

With reference toFIG.1, the vehicle100may be any passenger or commercial automobile such as a car, a truck, a sport utility vehicle, a crossover, a van, a minivan, a taxi, a bus, etc.

The vehicle system105includes the first control module110. The first control module110is a microprocessor-based computing device, e.g., a generic computing device including a processor and a memory, an electronic controller or the like, a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), a combination of the foregoing, etc. Typically, a hardware description language such as VHDL (VHSIC (Very High Speed Integrated Circuit) Hardware Description Language) is used in electronic design automation to describe digital and mixed-signal systems such as FPGA and ASIC. For example, an ASIC is manufactured based on VHDL programming provided pre-manufacturing, whereas logical components inside an FPGA may be configured based on VHDL programming, e.g., stored in a memory electrically connected to the FPGA circuit. The first control module110can thus include a processor, a memory, etc. The memory of the first control module110can include media for storing instructions executable by the processor as well as for electronically storing data and/or databases, and/or the first control module110can include structures such as the foregoing by which programming is provided.

The vehicle system105includes the vehicle network120. The first control module110may transmit and receive data through the vehicle network120. The vehicle network120may be or include a controller area network (CAN) bus, Ethernet, WiFi, Local Interconnect Network (LIN), onboard diagnostics connector (OBD-II), and/or by any other wired or wireless communications network. The vehicle network120may communicatively couple the first control module110, the second control modules115, third control modules125, a transceiver130, and other components of the vehicle100.

The vehicle system105includes the second control modules115. The second control modules115are microprocessor-based computing devices, e.g., generic computing devices including respective processors and memories, electronic controllers or the like, field-programmable gate arrays (FPGA), application-specific integrated circuits (ASIC), combinations of the foregoing, etc. Typically, a hardware description language such as VHDL (VHSIC (Very High Speed Integrated Circuit) Hardware Description Language) is used in electronic design automation to describe digital and mixed-signal systems such as FPGA and ASIC. For example, an ASIC is manufactured based on VHDL programming provided pre-manufacturing, whereas logical components inside an FPGA may be configured based on VHDL programming, e.g., stored in a memory electrically connected to the FPGA circuit. The second control modules115can thus each include a processor, a memory, etc. The memories of the second control modules115can include media for storing instructions executable by the processors as well as for electronically storing data and/or databases, and/or the second control modules115can include structures such as the foregoing by which programming is provided.

The vehicle system105may include the third control modules125. The term “third control modules” is used herein to refer to control modules that do not use authentication keys210from the update command200. For example, communications to and from the third control modules125may be unencrypted. The third control modules125are microprocessor-based computing devices, e.g., generic computing devices including respective processors and memories, electronic controllers or the like, field-programmable gate arrays (FPGA), application-specific integrated circuits (ASIC), combinations of the foregoing, etc. Typically, a hardware description language such as VHDL (VHSIC (Very High Speed Integrated Circuit) Hardware Description Language) is used in electronic design automation to describe digital and mixed-signal systems such as FPGA and ASIC. For example, an ASIC is manufactured based on VHDL programming provided pre-manufacturing, whereas logical components inside an FPGA may be configured based on VHDL programming, e.g., stored in a memory electrically connected to the FPGA circuit. The third control modules125can thus each include a processor, a memory, etc. The memories of the third control modules125can include media for storing instructions executable by the processors as well as for electronically storing data and/or databases, and/or the third control modules125can include structures such as the foregoing by which programming is provided.

The second control modules115and third control modules125are programmed for performing different functions for the vehicle100. For example, the second control modules115and third control modules125may include an engine control module, a body control module, a restraint control module, an accessory control module, a power-steering control module, an antilock brake control module, etc. The vehicle100may contain between fifty and one hundred control modules110,115,125.

The vehicle system105may include the transceiver130. The transceiver130may be adapted to transmit signals wirelessly through any suitable wireless communication protocol, such as cellular, Bluetooth®, Bluetooth® Low Energy (BLE), ultra-wideband (UWB), WiFi, IEEE 802.11a/b/g/p, cellular-V2X (CV2X), Dedicated Short-Range Communications (DSRC), other RF (radio frequency) communications, etc. The transceiver130may be adapted to communicate with a remote server135, that is, a server distinct and spaced from the vehicle100. The transceiver130may be one device or may include a separate transmitter and receiver.

The remote server135may be located outside the vehicle100. For example, the remote server135may be associated with a manufacturing facility or service center for the vehicle100, another vehicle (e.g., V2V communications), an infrastructure component (e.g., V2I communications), an emergency responder, a mobile device associated with the owner of the vehicle100, etc.

The second control modules115are programmed to encrypt and decrypt messages with the authentication keys210. For example, the authentication keys210may be symmetric encryption keys. Two (at least) second control modules115may store the same authentication key210. One of the two second control modules115may encrypt a message using the authentication key210and transmit the message to the other of the two second control modules115, and the other of the two second control modules115may decrypt the message using that same authentication key210.

The second control modules115may belong to groups140. The second control modules115in each group140may be associated with one of the authentication keys210, e.g., there is a one-to-one correspondence between the groups140and the authentication keys210. Each second control module115in one of the groups140may be programmed to encrypt messages to others of the second control modules115in that group140with the authentication key210associated with that group140. More than one of second control modules115, i.e., one of the groups140, may be associated with each authentication key210. Each group140may correspond to a function or feature of the vehicle100, e.g., braking, steering, drivetrain, climate control of a passenger cabin, infotainment, etc. Each second control module115may belong to one or multiple groups140, e.g., a second control module115that reports a speed of the vehicle100may belong to a group140for braking and a group140for drivetrain.

With reference toFIG.2, the update command200includes a listing205of the authentication keys210. For example, the listing205may form a payload of the update command200. The update command200may lack an association between the authentication keys210and the second control modules115.

The listing205of the authentication keys210may include the authentication keys210paired with respective key identifiers215. Each key identifier215may be a string uniquely specifying one of the authentication keys210. The authentication keys210and the key identifiers215may have a one-to-one correspondence. The listing205may include the pairs of key identifiers215and authentication keys210concatenated together.

The authentication keys210in the update command200may be encrypted, i.e., an encryption algorithm may be executed on the authentication key210. For example, the encryption algorithm can be any suitable algorithm, e.g., Advanced Encryption Standard (AES). For another example, a hash algorithm may be executed on the authentication key210. The hash algorithm can be a cryptographic hash function, e.g., a keyed cryptographic hash function such as BLAKE2, BLAKE3, HMAC, KMAC, MD6, one-key MAC, PMAC, Poly1305-AES, SipHash, HighwayHash, UMAC, VMAC, etc., or may be a simpler hash function such as MD5. The authentication keys210in the update command200may be differently encrypted from each other. For example, the authentication keys210may be encrypted with an encryption key unique to each second control module115and known only to the remote server135. For another example, the authentication keys210may be hashed with a keyed cryptographic hash function that keyed from a different value for each authentication key210. The independent encryption may prevent the second control modules115from accessing unassociated authentication keys210.

FIG.3is a sequence diagram illustrating an example process300for the first control module110of the vehicle100to distribute the authentication keys210to the second control modules115. The memories of the remote server135, the first control module110, and/or the second control modules115may store executable instructions for performing the steps of the process300and/or programming can be implemented in structures such as mentioned above.

The process300begins in a step305, in which the remote server135transmits a first configuration file to the first control module110, e.g., via the transceiver130, and the first control module110receives the first configuration file. The first configuration file indicates the groups140of the second control modules115. The groups140may be identified by, e.g., the key identifiers215of the associated keys or by some other unique identifier. The second control modules115may be identified by the module identifiers. The first configuration file may include the authentication keys210, or the authentication keys210may already be loaded onto the first control module110.

Next, in a step310, the remote server135transmits respective second configuration files to the second control modules115, e.g., via the transceiver130, and the second control modules115receive the respective second configuration files. The second configuration file for each second control module115indicates the groups140to which that second control module115belongs. The second configuration file for each second control module115may lack an indication of the groups140to which other second control modules115belong. Each second configuration file may further indicate the authentication keys210that are associated with the respective second control module115, e.g., by listing the key identifiers215for the authentication keys210that are associated with that second control module115. Each second configuration file may not indicate, i.e., may lack an indication of, the authentication keys210that are associated with others of the second control modules115besides the respective second control module115.

Next, in a step315, the remote server135transmits a transmission command to the first control module110, and the first control module110receives the transmission command. The transmission command instructs the first control module110to transmit the update command200to the second control modules115. The transmission command may be signed with a digital signature, i.e., may include signature data encrypted with a private key. The transmission command may be triggered by an input from an operator of the remote server135or by the vehicle100entering a particular section of the manufacturing process.

Next, in a step320, the first control module110validates the transmission command. For example, the first control module110may decrypt the signature data in the transmission command using a public key corresponding to the private key used by the remote server135to sign the transmission command. The first control module110refrains from transmitting the update command200until the transmission command is validated.

Next, in a step325, the first control module110generates the update command200in response to receiving and validating the transmission command.

Next, in a step330, the first control module110transmits the update command200over the vehicle network120in response to receiving and validating the transmission command, e.g., upon generating the update command200, and the second control modules115receive the update command200. For example, the update command200may be functionally addressed to be receivable by the second control modules115. For the purposes of this disclosure, a message that is “functionally addressed” is defined as a message labeled based on the operation code or content of the message. Functional addressing is distinguished from physical addressing, i.e., identifying the particular control module110,115,125that should receive the message. The update command200may thus be receivable by any entity on the vehicle network120, i.e., the second control modules115as well as the third control modules125, which are not listed in the update command200.

Next, in a step335, each second control module115identifies the authentication keys210that are associated with that second control module115based on the respective second configuration file in response to receiving the update command200. For example, the second control module115may select the authentication keys210paired with the key identifiers215listed in the second configuration file sent to that second control module115.

Next, in a step340, each second control module115updates with the identified authentication keys210, e.g., with the authentication keys210of the key identifiers215from the respective second configuration file. For example, the second control module115may save the identified authentication keys210in memory associated with the respective groups140to which the second control module115belongs, for later use in encrypting and decrypting messages within those groups140, as described above.

Next, in a step345, each second control module115transmits a respective verification to the first control module110in response to receiving the update command200and updating with the identified authentication keys210, and the first control module110receives the plurality of verifications. The verifications indicate that the respective second control modules115received the update command200and updated with the authentication keys210.

Next, in a step350, the first control module110confirms completion of the distribution of the authentication keys210. For example, the first control module110may output a message indicating successful completion. After the step350, the process300ends.

FIG.4is a process flow diagram illustrating an example process400for the first control module110to distribute the authentication keys210. The memory of the first control module110stores executable instructions for performing the steps of the process400and/or programming can be implemented in structures such as mentioned above. As a general overview of the process400, the first control module110receives the first configuration file, receives the transmission command, validates the transmission command, generates the update command200, transmits the update command200, and waits for a predetermined period. Upon receiving the plurality of verifications from the second control modules115, the process400ends as a successful distribution. Upon failing to receive the verification from at least one of the second control modules115, the first control module110again generates the update command200, transmits the update command200, and waits for the predetermined period. Upon again failing to receive the verification from at least one of the second control modules115, the first control module110outputs an error message.

The process400begins in a block405, in which the first control module110receives the first configuration file indicating the groups140of the second control modules115, as described above.

Next, in a block410, the first control module110receives the transmission command, as described above.

Next, in a block415, the first control module110validates the transmission command, as described above.

Next, in a block420, the first control module110generates the update command200including the authentication keys210, as described above.

Next, in a block425, the first control module110transmits the update command200over the vehicle network120, as described above.

Next, in a block430, the first control module110waits to receive the verifications indicating that the second control modules115received the update command200. For example, the first control module110may wait for a predetermined period. The predetermined period may be chosen to encompass a range of typical times for all the second control modules115to transmit the verifications when no errors occur.

Next, in a decision block435, the first control module110determines whether the first control module110received the verifications from all the second control modules115, e.g., during the predetermined period. Upon receiving all the verifications, the process400ends. Upon failing to receive the verification from at least one of the second control modules115, the process400proceeds to a decision block440.

In the decision block440, the first control module110determines whether the first control module110has retransmitted the update command200over the vehicle network120at least once, i.e., has executed the block425at least a second time. If not, the process400returns to the block420to re-generate the update command200, retransmit the update command200, and rewait for the predetermined period. If so, the process400proceeds to a block445.

In the block445, the first control module110outputs an error message. The error message may indicate that the distribution of the authentication keys210was unsuccessful. The error message may include identifiers for the second control modules115from which the first control module110failed to receive the verifications. For example, the first control module110may transmit the error message to the remote server135and/or display the error message with a user interface of the vehicle100. After the block445, the process400ends.

FIG.5is a process flow diagram illustrating an example process500for one of the second control modules115to receive the authentication keys210. The memory of the second control module115stores executable instructions for performing the steps of the process500and/or programming can be implemented in structures such as mentioned above. As a general overview of the process500, the second control module115receives the second configuration file, receives the update command200, identifies the authentication keys210that are associated with the second control module115, updates with the identified authentication keys210, and transmits the verification.

The process500begins in a block505, in which the second control module115receives the second configuration file from the remote server135, as described above.

Next, in a block510, the second control module115receives the update command200from the first control module110, as described above.

Next, in a block515, the second control module115identifies the authentication keys210that are associated with the second control module115based on the second configuration file, as described above.

Next, in a block520, the second control module115updates with the identified authentication keys210, as described above.

Next, in a block525, the second control module115transmits the verification to the first control module110, as described above. After the block525, the process500ends.

A computer-readable medium (also referred to as a processor-readable medium) includes any non-transitory (e.g., tangible) medium that participates in providing data (e.g., instructions) that may be read by a computer (e.g., by a processor of a computer). Such a medium may take many forms, including, but not limited to, non-volatile media and volatile media. Instructions may be transmitted by one or more transmission media, including fiber optics, wires, wireless communication, including the internals that comprise a system bus coupled to a processor of a computer. Common forms of computer-readable media include, for example, RAM, a PROM, an EPROM, a FLASH-EEPROM, any other memory chip or cartridge, or any other medium from which a computer can read.

In the drawings, the same reference numbers indicate the same elements. Further, some or all of these elements could be changed. 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 could be practiced with the described steps performed in an order other than the order described herein. It further should be understood that certain steps could be performed simultaneously, that other steps could be added, or that certain steps described herein could be omitted.

All terms used in the claims are intended to be given their plain and ordinary meanings as understood by those skilled in the art unless an explicit indication to the contrary in made herein. In particular, use of the singular articles such as “a,” “the,” “said,” etc. should be read to recite one or more of the indicated elements unless a claim recites an explicit limitation to the contrary. The adjectives “first” and “second” are used throughout this document as identifiers and are not intended to signify importance, order, or quantity. Use of “in response to” and “upon determining” indicates a causal relationship, not merely a temporal relationship.