System and method for providing secured can communications

Abstract

To provide a method.SOLUTION: Example embodiments of the present disclosure provide secured CAN communications between vehicle components. According to embodiments, a method for providing may include: generating, by at least one processing unit of a sender, a one-time passcode (OTP); obtaining, by the at least one processing unit of the sender, a master key pre-provisioned to the sender and a receiver; deriving, by the at least one processing unit of the sender, a shared key based on the OTP and the master key; generating, by the at least one processing unit of the sender, a message authentication code (MAC) based on the derived shared key; appending, by the at least one processing unit of the sender, the MAC to a message; and transmitting, by the at least one processing unit of the sender, the appended message to the receiver via a CAN bus.SELECTED DRAWING: Figure 5

Description

[Technical Field]

[0001] Exemplary embodiments of the present disclosure relate to vehicle systems, and more particularly to providing secure Controller Area Network (CAN) communications between components of one or more vehicle systems. [Background technology]

[0002] In the automotive field, electronic control units (ECUs) are widely used as embedded systems for controlling various functions within a vehicle and its associated systems. Such functions may include, for example, engine management, transmission control, stability control, powertrain control, airbag control, and the like. Generally, the operation of an ECU involves data exchange and communication between the ECU and other vehicle components (e.g., other ECUs, sensors, actuators, etc.). Such data exchange and communication is performed via one or more buses, such as a CAN bus, an Ethernet bus, and the like. In particular, the CAN bus has been widely adopted because it provides a high level of reliability for multiple ECUs and devices to communicate with each other in real time.

[0003] To provide correct, safe, and reliable vehicle functions, it is important to ensure the security of communication and data exchange between ECUs and other vehicle components. Although the CAN bus can provide simple yet efficient communication between ECUs and vehicle components, it is not secure by design because authentication, confidentiality, and integrity are not considered in the design and implementation of the associated protocol. Related technologies have introduced several safety mechanisms for authentication and integrity protection to improve the security of CAN bus communication. For example, the Automotive Open Systems Architecture (AUTOSAR) provides a Secure On-Board Communication (SecOC) module to secure communication between ECUs in a CAN bus network, thereby ensuring that data received by an ECU originates from the correct ECU and has the correct value.

[0004]

[0013] Referring to Figure 1, Figure 1 shows a diagram of an exemplary implementation of a SecOC module in the related art. In the example of Figure 1, a transmitter 110 is configured to communicate with a receiver 120 by sending protocol data units (PDUs) to the receiver 120. The transmitter 110 and the receiver 120 may each be an ECU, and each may be pre-provisioned with a static shared secret key.

[0005] Before transmitting a PDU to receiver 120, transmitter 110 calculates a message authentication code (MAC) using a shared secret key and then appends or adds the MAC information to the PDU to create a secure PDU. The secure PDU is then transmitted to receiver 120, for example, via a CAN bus. Receiver 120 receives the secure PDU and calculates another MAC using the same shared secret key. Receiver 120 can then use the other MAC to authenticate the secure PDU. For example, if the MAC calculated by receiver 120 matches the MAC included in or appended to the secure PDU, receiver 120 can thereby determine that the secure PDU was sent by a trusted transmitter and has not been tampered with, after which the PDU can be further used. Otherwise, receiver 120 can determine that the MAC authentication failed and then reject or discard the received PDU.

[0006] The above-described implementation of the SecOC module requires the pre-provisioning and sharing of a static secret key between ECUs. Although the related art has introduced the use of a Hardware Security Module (HSM) to secure the static shared secret key, under certain circumstances, the key still needs to be pre-provisioned to ECUs that do not have any HSM, so there is still a risk that the key can be easily compromised.

[0007] In this regard, because the shared secret key is static between ECUs, compromising the shared secret key even once may enable an attacker to attack all associated ECUs. For example, based on the compromised secret key, an attacker may perform a CAN injection attack to inject or send spoofed / fake signals to manipulate information processed by the target ECU. This may enable the attacker to control critical safety functions of the target vehicle, such as turning off the vehicle's brakes, triggering airbag deployment, causing vehicle components to give false readings, and the like.

[0008] For at least the above reasons, there is a need to provide improved, secure CAN communications between vehicle components, particularly between ECUs and other vehicle components. Summary of the Invention

[0009] Exemplary embodiments consistent with the present disclosure provide methods, systems, and apparatus for dynamically deriving a shared secret key that is absent when the vehicle is in an ignition-off (IG-OFF) state and that changes each time the vehicle enters an ignition-on (IG-O) state, thereby providing improved CAN communication between vehicle components.

[0010] According to an embodiment, a method for providing secure CAN communication between a transmitter and a receiver is provided. The method may include generating, by at least one processing unit of the transmitter, a one-time passcode (OTP), obtaining, by the at least one processing unit of the transmitter, a master key previously provided to the transmitter and the receiver, deriving, by the at least one processing unit of the transmitter, a shared key based on the OTP and the master key, generating, by the at least one processing unit of the transmitter, a message authentication code (MAC) based on the derived shared key, appending, by the at least one processing unit of the transmitter, the MAC to a message, and transmitting, by the at least one processing unit of the transmitter, the appended message to the receiver via a CAN bus.

[0011] According to an embodiment, a system for providing secure CAN communications between a transmitter and a receiver is provided. The system may include a memory storage configured to store computer-executable instructions and at least one processing unit communicatively coupled to the memory storage. The at least one processing unit may be configured to generate a one-time passcode (OTP), obtain a master key previously provided to the transmitter and receiver, derive a shared key based on the OTP and the master key, generate a message authentication code (MAC) based on the derived shared key, append the MAC to a message, and transmit the appended message to the receiver via a CAN bus.

[0012] Additional aspects will be set forth in part in the description that follows, and in part will be apparent from the description, or may be learned by practice of presented embodiments of the present disclosure. [Brief explanation of the drawings]

[0013] The features, advantages, and importance of preferred embodiments of the present disclosure will now be described with reference to the accompanying drawings, in which like reference numerals refer to like elements. [Figure 1]FIG. 1 shows a diagram of an exemplary implementation of a SecOC module in the related art. [Figure 2] FIG. 2 illustrates a diagram of example operations for dynamically deriving a shared key in accordance with one or more example embodiments. [Figure 3] FIG. 3 illustrates a diagram of an example implementation of a SecOC module, according to one or more example embodiments. [Figure 4] FIG. 4 illustrates a block diagram of example components of an ECU, according to one or more example embodiments. [Figure 5] FIG. 5 illustrates a flow diagram of an exemplary method for providing secure CAN communications between a transmitter and a receiver. [Figure 6] FIG. 6 illustrates a flow diagram of an exemplary method for providing secure CAN communications between a transmitter and a receiver. DETAILED DESCRIPTION OF THE INVENTION

[0014] The following detailed description of preferred embodiments refers to the accompanying drawings. The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit implementations to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of implementations. Furthermore, one or more features or components of one embodiment may be incorporated into or combined with another embodiment (or one or more features of another embodiment). Furthermore, in the flowcharts and descriptions of operations provided below, it is understood that one or more operations may be omitted, one or more operations may be added, one or more operations may be performed (at least partially) concurrently, or the order of one or more operations may be swapped.

[0015] Although a particular combination of features is recited in a claim and / or disclosed herein, such combination is not intended to limit the disclosure of possible implementations. Indeed, many of the features may be combined in ways not specifically recited in the claims and / or disclosed herein. Although each dependent claim listed below may depend directly on only one claim, the disclosure of possible implementations includes each dependent claim in combination with all other claims in the claim set.

[0016] No element, act, or instruction used herein should be construed as critical or required unless expressly stated otherwise. Also, as used herein, the articles "a" and "an" are intended to include one or more items and may be used interchangeably with "one or more." Where only one item is intended, the term "a" or similar terms are used. Also, as used herein, the terms "has," "have," "having," "include," "including," or the like are intended to be open-ended terms. Furthermore, the phrase "based on" is intended to mean "based at least in part on," unless expressly stated otherwise. Furthermore, phrases such as "[A] and / or [B]," "at least one of [A] and [B]," or "at least one of [A] or [B]" should be understood to include A only, B only, or both A and B.

[0017] References throughout this specification to "one embodiment," "an embodiment," "a non-limiting preferred embodiment," or similar terms mean that the particular features, structures, or characteristics described in connection with the illustrated embodiment are included in at least one embodiment of the solution. Thus, the phrases "in one embodiment," "in an embodiment," "a non-limiting preferred embodiment," and similar terms throughout this specification may, but do not necessarily, all refer to the same embodiment.

[0018] Furthermore, the described features, advantages, and characteristics of the present disclosure may be combined in any suitable manner in one or more exemplary embodiments. Those skilled in the art will recognize, in light of the description herein, that the present disclosure may be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the present disclosure.

[0019] Furthermore, the term "vehicle" as used herein refers to any suitable type of vehicle in which exemplary embodiments of the present disclosure may be implemented. For example, a "vehicle" may refer to a motorized vehicle, such as a car, truck, bus, motorcycle, or any other suitable type of motor vehicle powered by an engine, motor, or other mechanical means. Alternatively, or in addition, a "vehicle" as used herein may refer to a bicycle, skateboard, and any other suitable type of non-motorized vehicle without departing from the scope of the present disclosure.

[0020] Additionally, although example embodiments of the present disclosure are described herein with reference to communication between ECUs, it is contemplated that the example embodiments may also be applicable to provide secure communication between other vehicle components, for example, between ECUs and on-board sensors, between ECUs and actuators, between on-board sensors and actuators, and the like, without departing from the scope of the present disclosure.

[0021] The systems and methods of the related art described above require a static shared key to be pre-provisioned in the ECU, so that the ECU can generate a MAC using the static shared key and then authenticate the communication message in terms of authenticity and integrity based on the MAC. In contrast, exemplary embodiments of the present disclosure do not require a static shared key to be pre-provisioned in the ECU. Rather, the exemplary embodiments of the present disclosure derive a symmetric key using variable parameters, for example, according to the vehicle state. For example, each ECU that communicates with other vehicle components (e.g., other ECUs, sensors, actuators, etc.) via a CAN bus can derive the same key when the vehicle changes from an ignition-off (IG-OFF) state to an ignition-on (IG-ON) state (e.g., when the vehicle is first started), and the derived shared key can then be used to secure communication between the ECUs. This shared key does not exist when the vehicle is in the IG-OFF state; instead, the shared key is dynamically derived when the vehicle starts and is different each time the vehicle enters the IG-ON state. Exemplary operations associated with deriving a key, according to one or more exemplary embodiments, are described below with reference to FIG.

[0022] 2 illustrates a diagram of example operations for dynamically deriving a shared key, according to one or more example embodiments. Passcode generator 210 and key derivation module 220 in FIG. 2 may be implemented as functional modules of an ECU and may be implemented in various forms, such as hardware, firmware, or a combination of hardware and software. In this regard, it is contemplated that one or more operations described herein with reference to passcode generator 210 and key derivation module 220 may be performed by hardware (e.g., a processing unit, etc.) executing software or computer-executable instructions to implement passcode generator 210 and key derivation module 220.

[0023] The passcode generator 210 may be configured to generate one or more one-time passcodes (OTPs) and then provide the generated OTP(s) to the key derivation module 220 for further processing. The generation of the OTPs may be initiated or triggered according to the state of the vehicle. For example, whenever the vehicle changes from an IG-OFF state to an IG-ON state, the ECUs may be powered on, and the generation of the OTPs may be automatically initiated in each of the ECUs whose communications with other vehicle components need to be authenticated by a message authentication code (MAC).

[0024] According to an exemplary embodiment, passcode generator 210 may be configured to obtain timestamp 211 information, geographic location 212 information, and master seed 213 information, and then generate one or more OTPs based on the timestamp, geographic location, and master seed.

[0025] The timestamp 211 may be associated with when the vehicle changes from an IG-OFF state to an IG-ON state (e.g., when the vehicle is first started). The passcode generator 210 may obtain the timestamp information from an internal clock in the ECU, where the internal clock may be configured to record and provide timestamp information associated with a vehicle state (e.g., when the vehicle first enters the IG-ON state, when the vehicle is in park, etc.).

[0026] According to an example embodiment, upon receiving the timestamp, passcode generator 210 may truncate the timestamp according to a tolerance level. For example, based on a predetermined tolerance level, passcode generator 210 may discard the millisecond component of the timestamp to achieve a tolerance level in terms of seconds, may round the timestamp to the nearest integer second, or the like. In this way, each ECU may generate the same OTP (and thereby derive the same key) as long as the timestamp is within the tolerance level.

[0027] The geographic location 212 may be associated with the location of the vehicle (where the ECU is deployed), such as the latitude and longitude coordinates (or other location and / or position data) of the vehicle when the vehicle enters the IG-ON state. The passcode generator 210 may obtain the geographic location information through various means, such as Global Positioning System (GPS) linkage, Inertial Navigation System (INS) measurements, cellular or Wi-Fi triangulation, and the like.

[0028] The master seed 213 may comprise a set of values ​​securely stored within the memory or firmware of the ECU. The master seed may be pre-provided to the ECU by the vehicle manufacturer or system administrator during the ECU's manufacturing or initialization process. Access to and use of the master seed is restricted to only the passcode generator 210.

[0029] Upon obtaining timestamp 211, geographic location 212, and master seed 213, passcode generator 210 may combine this information or data to generate one or more OTPs. For example, passcode generator 210 may perform one or more operations, such as concatenation, cryptographic hashing, cryptographic signing, and the like, to generate one or more OTPs based on the timestamp, geographic location, and master seed. Thus, whenever the vehicle changes from an IG-OFF state to an IG-ON state, because the timestamp and / or the vehicle's geographic location change, passcode generator 210 may generate and provide a unique dynamic OTP to key derivation module 220 to derive one or more unique dynamic shared keys.

[0030] Key derivation module 220 may be configured to obtain one or more OTPs (from passcode generator 210) and master key 230, and then derive shared key 240 therefrom. Master key 230 may include a secret cryptographic key used as the basis for deriving shared key 240 and may be pre-provided to each of the ECUs during a manufacturing or initialization process.

[0031] The key derivation module 220 may combine the unique OTP (provided by the passcode generator 210) with the master key 230, thereby deriving a unique shared key 240. The key derivation module 220 may implement one or more cryptographic algorithms, such as a key derivation function (KDF), a hash-based function (e.g., SHA-256, SHA-512, etc.), and the like, to derive the shared key 240 based on the OTP and the master key 230. Similar to the generation of the OTP, the derivation of the shared key may also be initiated or triggered according to the state of the vehicle. For example, whenever the vehicle changes from an IG-OFF state to an IG-ON state, the ECUs may be powered on, and the derivation of the shared key may be automatically initiated in each of the ECUs after the generation of the OTP.

[0032] 2 is merely one possible configuration, and it is contemplated that actual implementations of example embodiments are not limited thereto. Specifically, in some implementations, multiple master seeds 213 and / or multiple master keys 230 may be involved in the process of deriving shared key 240, timestamp 211 may be obtained from a component external to the ECU, and the like, without departing from the teachings of this disclosure.

[0033] In view of the above, exemplary embodiments of the present disclosure may provide a unique dynamic shared key each time a vehicle changes, for example, from an IG-OFF state to an IG-ON state. The shared key does not exist when the vehicle is in the IG-OFF state and changes each time the vehicle enters the IG-ON state. Therefore, the risk of the shared key being compromised may be significantly reduced compared to the related art's use of a pre-provided static shared key.

[0034] Next, exemplary operations by which the derived shared key is implemented, according to one or more exemplary embodiments, are described below with reference to Figure 3. Specifically, Figure 3 illustrates a diagram of an exemplary implementation of a SecOC module, according to one or more exemplary embodiments.

[0035] In the example of Figure 3, transmitter 310 is configured to communicate with receiver 320 by transmitting protocol data units (PDUs). Transmitter 310 and receiver 320 may each be an ECU and may each include a passcode generator and key derivation module (described above with reference to Figure 2). By utilizing the passcode generator and key derivation module, transmitter 310 and receiver 320 may each generate a unique shared key when they are initially powered on (when the vehicle initially enters the IG-ON state). Detailed descriptions associated with the derivation of the shared key are described above with reference to Figure 2, and therefore, redundant descriptions associated therewith may be omitted for the sake of brevity.

[0036] The general operations in Figure 3 for securing a PDU via MAC generation and MAC authentication may be similar to those described in Figure 1. The difference between the implementations of Figure 3 and Figure 1 is that the shared key in Figure 1 is static and pre-provisioned to the transmitter and receiver, while the shared key in Figure 3 is dynamically generated by the transmitter and receiver when they are first powered on. Additionally, Figure 3 utilizes an optional monotonic counter to provide one or more counter values, such that the transmitter 310 and receiver 320 may utilize the one or more counter values ​​to secure the PDU in addition to the derived shared key.

[0037] Before transmitting the PDU to the receiver 320, the transmitter 310 calculates a message authentication code (MAC) using a derived shared key (derived by the transmitter 310 when the transmitter 310 is first powered on), and then adds the MAC information to the PDU to create a secure PDU.

[0038] Optionally, the computation of the MAC and the creation of the secure PDU may further involve a counter value in addition to the derived shared key. In the example of FIG. 3, the transmitter 310 includes a monotonic counter that increments over time, and whenever the transmitter 310 transmits a message in the network, it provides a counter value associated with this monotonic counter. In this regard, the monotonic counters at the transmitter 310 and the receiver 320 may be synchronized during start-up or communication initialization to ensure that both the transmitter 310 and the receiver 320 have matching starting points for their monotonic counters to prevent problems such as message rejection due to large initial counter differences and the like. Because use of the counter value may provide freshness to messages, in some implementations the counter value may also be referred to as a "freshness value."

[0039] If a counter value is involved, the transmitter 310 may obtain the counter value from the monotonic counter and then generate a MAC based on both the counter value and the derived shared key. Additionally, the transmitter 310 may also append both the counter value and the generated MAC to a message (e.g., a PDU), thereby creating an appended message (e.g., a secure PDU).

[0040] According to an example embodiment, the transmitter 310 may truncate the MAC and counter value and then append the truncated MAC and truncated counter value to the PDU to create a secure PDU. For example, the MAC and counter value may be truncated according to one or more tolerance levels. Alternatively, or in addition, the MAC and counter value may be truncated to the most significant bits. Truncation of the MAC and counter value may be desirable when the message payload is limited in length and / or does not have enough space to contain the entire MAC and / or counter value.

[0041] Upon generating the appended message (e.g., a secure PDU), the transmitter 310 may transmit the appended message to the receiver 320, for example, via a CAN bus. The receiver 320 receives the appended message and authenticates it before further use. Specifically, the receiver 320 may calculate another MAC using a derived shared key (derived by the receiver 320 when the receiver 320 is first powered on) and then use the another MAC to authenticate the appended message. For example, if the MAC calculated by the receiver 320 matches the MAC included in or appended to the message, the receiver 320 may thereby determine that the appended message is authenticated and sent by a trusted transmitter / not tampered with, and may then extract the message from the appended message for further use. Otherwise, the receiver 320 may determine that the MAC authentication failed and the appended message is not authenticated, and may then reject or discard the received message.

[0042] According to an exemplary embodiment in which the appended message includes a counter value, the receiver 320 may also check the counter value included in the appended message upon receiving the appended message. For example, the receiver 320 may obtain information about a previously received counter value and then compare the last received counter value with the counter value included in the appended message. If the counter value in the appended message is greater than the previously received counter value, the newly received appended message is considered new and valid, and the receiver 320 may update the previously stored counter value to the newly received counter value included in the appended message. Thus, the receiver 320 may use the derived shared key plus the latest counter value (stored in the receiver's 320 memory or provided by the receiver's 320 monotonic counter) to calculate a MAC to authenticate the appended message. On the other hand, if the counter value in the appended message is less than or equal to the previously received counter value, the newly received appended message may be considered stale or a potential replay attack, and the receiver 320 may reject or discard the newly received appended message.

[0043] 4, which illustrates a block diagram of exemplary components of an ECU 400, according to one or more exemplary embodiments. ECU 400 may include one or more ECUs responsible for control of various vehicle functions, such as ECUs responsible for engine management, transmission control, braking systems, and the like. In this regard, it is contemplated that each of transmitter 310 and receiver 320 (and functional modules such as a passcode generator and key derivation module) and associated operations described herein above may be implemented by ECU 400.

[0044] 4, ECU 400 may include at least one bus 410, at least one processing unit 420, at least one memory 430, at least one storage unit 440, at least one input unit 450, at least one output unit 460, and at least one communication interface 470. It is contemplated that ECU 400 may include more or fewer components than those shown in FIG. 4 without departing from the scope of the present disclosure. For example, in some embodiments, ECU 400 may include multiple storage units 440, where input unit 450 and output unit 460 may be implemented as transceiver components, memory 430 and storage unit 440 may be implemented as memory storage, and the like.

[0045] Bus 410 may be configured to facilitate or enable communication between components of ECU 400. In particular, bus 410 may communicatively couple the components to one another and provide a means for data movement and flow of control signals between the components. Bus 410 may include one or more of an internal bus, an address bus, a data bus, a control bus, and any other suitable type of bus that may be implemented in ECU 400 to enable communication and coordination between components within ECU 400.

[0046] Processing unit 420 may be implemented in hardware, firmware, or a combination of hardware and software and may be configured to handle real-time (or near-real-time) data processing and control of ECU 400. Processing unit 420 may include one or more of a microcontroller unit (MCU), a microprocessor, a digital signal processor (DSP), a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), a system-on-chip (SoC), a central processing unit (CPU), a graphics processing unit (GPU), and any other suitable type of processing unit that may be implemented in ECU 400. In some implementations, processing unit 420 may be programmable to perform one or more operations described herein. Furthermore, processing unit 420 may include multiple processing units, each dedicated to performing a particular operation (e.g., one processing unit may be assigned to perform the operations of a passcode generator, one processing unit may be assigned to perform the operations of a key derivation module, etc.).

[0047] Memory 430 may include one or more media for storing temporary data, runtime variables, program instructions, and buffers necessary for the operation of the ECU. Memory 430 may include one or more of flash memory, read-only memory (ROM), random access memory (RAM), dynamic or static storage devices, and any other suitable type of memory that may be implemented in ECU 400.

[0048] The storage unit 440 may be configured to store non-volatile data, such as firmware, configuration settings, calibration data, and other persistent information necessary for the operation of the ECU. For example, the storage unit 440 may store one or more counter values, one or more pre-provisioned master seeds, one or more pre-provisioned master keys, one or more pre-defined tolerance levels, and the like. Furthermore, the storage unit 440 may also store computer-readable or computer-executable instructions for implementing one or more operations described herein. The storage unit 440 may provide the stored information to the memory 430 for execution by the processor 420. The storage unit 440 may include one or more of a flash memory, a read-only memory (ROM), a solid-state storage medium, and any other suitable type of storage component that may be implemented in the ECU 400.

[0049] Input section 450 may include one or more input components that enable ECU 400 to receive information from one or more external vehicle components, such as one or more sensors (e.g., engine sensors that provide signals regarding IG-OFF and IG-ON states, etc.), one or more positioning systems (e.g., a global positioning system (GPS), an inertial navigation system (INS), etc.) that provide geographic location information for the vehicle in which ECU 400 is deployed, timing devices (e.g., an internal clock, a real-time clock (RTC), etc.) that provide timestamp information, counters (e.g., monotonic counters, etc.) that provide counter values, and the like. Additionally, input section 450 may also include components that enable ECU 400 to receive one or more user inputs (e.g., user input to provide updates regarding the master seed and master key, etc.). According to an exemplary embodiment, input 450 may include a local interconnect network (LIN) receiver, a CAN bus receiver, a CAN transceiver, a FlexRay transceiver, a radio transceiver, and the like, that allows ECU 400 to receive messages or data from other vehicle components (e.g., another ECU, etc.).

[0050] Output 460 may include one or more output components that enable ECU 400 to provide information to one or more external components, such as one or more sensors and the like. Additionally, output 460 may also include components that enable ECU 400 to output information (e.g., a determination of an unverified message, etc.) to one or more users. According to an example embodiment, output 460 may include a LIN transmitter, a CAN bus transmitter, a CAN transceiver, a FlexRay transceiver, a wireless transceiver, and the like that enable ECU 400 to transmit messages or data to another vehicle component (e.g., another ECU, etc.).

[0051] Communication interface 470 may include one or more interfaces that facilitate communication of components of ECU 400 with one or more external vehicle components. For example, communication interface 470 may facilitate the exchange of messages or data between ECU 400 and another ECU, between ECU 400 and sensors / actuators, and the like. According to an example embodiment, communication interface 470 may include a CAN controller interface that manages the transmission and reception of messages for ECU 400 over a CAN bus. Additionally, communication interface 470 may include one or more application programming interfaces (APIs) that enable ECU 400 (or one or more components included therein) to communicate with one or more software applications (e.g., software applications deployed in another ECU).

[0052] In response to at least one processing unit 420 executing computer-executable instructions for implementing one or more of the operations described herein, ECU 400 may perform one or more of the operations described herein. The computer-executable instructions may be stored by a non-transitory computer-readable recording medium, such as memory 430 and / or storage unit 440. A computer-readable medium is defined herein as a non-transitory memory device. A memory device may include memory space within a single physical storage device or memory space spanning multiple physical storage devices.

[0053] Computer-executable instructions (e.g., software instructions, etc.) may be loaded into memory 430 and / or storage unit 440 from another computer-readable medium or from another device (e.g., a remote server, external storage, etc.) via communications interface 470. When executed, the computer-executable instructions stored in memory 430 and / or storage unit 440 may cause processing unit 420 to perform one or more processes described herein. Additionally or alternatively, hardwired circuitry may be used in place of or in combination with software instructions to perform one or more processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.

[0054] 5 illustrates a flow diagram of a method 500 for providing secure CAN communications between a transmitter and a receiver, according to one or more exemplary embodiments. The method may be implemented by at least one processing unit (e.g., processing unit 420) of a transmitter (e.g., transmitter 310) executing computer-readable instructions stored in one or more memory storages (e.g., memory 430, storage section 440, etc.). Method 500 may be triggered whenever the transmitter has a message to send to the receiver. The transmitter may be a first ECU, and the receiver may be a second ECU communicatively coupled to the first ECU via a CAN bus, for example.

[0055] 5, at operation S510, at least one processing unit of the transmitter may be configured to generate a one-time passcode (OTP). Specifically, the at least one processing unit may obtain a master seed previously provided to the transmitter and receiver (e.g., from memory storage), obtain a timestamp (e.g., from an internal clock), and obtain a geographic location of the vehicle in which the transmitter is deployed (e.g., from a location system). Thus, the at least one processing unit may generate the OTP based on the master seed, the timestamp, and the geographic location. According to an example embodiment, the at least one processing unit may be configured to generate the OTP by truncating the timestamp according to a tolerance level and then generating the OTP based on the master seed, the truncated timestamp, and the geographic location.

[0056] At operation S520, at least one processing unit of the transmitter may be configured to obtain a master key. The master key may be provided to the transmitter and receiver in advance and stored in memory storage of the transmitter and receiver. It is contemplated that operations S510 and S520 may be performed in any suitable sequence (e.g., operation S520 may be performed simultaneously with operation S510, operation S520 may be performed before operation S510, etc.) without departing from the scope of this disclosure.

[0057] Upon receiving the master key, method 500 may proceed to operation S530, where at least one processing unit of the transmitter may be configured to derive a shared key based on the OTP (generated in operation S510) and the master key (obtained in operation S520). According to an example embodiment, the timestamp may be associated with timing information of the vehicle changing from an ignition-off (IG-OFF) state to an ignition-on (IG-ON) state. In this case, the derived shared key may include a unique random number that changes each time the vehicle enters the IG-ON state from the IG-OFF state.

[0058] The specific operations associated with deriving the shared key are described above with reference to Figures 2 and 3. Accordingly, redundant descriptions associated therewith may be omitted below for the sake of brevity.

[0059] Upon deriving the shared key, method 500 may proceed to operation S540, where at least one processing unit of the transmitter may be configured to generate a message authentication code (MAC) based on the derived shared key. According to an example embodiment, the at least one processing unit may obtain a counter value (e.g., from a monotonic counter) and then generate the MAC based on the derived shared key and the counter value.

[0060] Upon generating the MAC, method 500 may proceed to operation S550, where at least one processing unit at the transmitter may be configured to append the MAC to a message. The message may include a protocol data unit (PDU). According to an example embodiment involving a counter value, the at least one processing unit may append the MAC to the message by truncating the counter value and the MAC and then appending the truncated MAC and the truncated counter value to the message.

[0061] Upon appending the MAC to the message, method 500 may proceed to operation S560, where at least one processing unit of the transmitter may be configured to transmit the appended message to the receiver via the CAN bus.

[0062] The specific operations associated with generating a MAC, appending the MAC to a message, and transmitting the appended message are described above with reference to Figure 3. Accordingly, redundant descriptions associated therewith may be omitted below for the sake of brevity.

[0063] 6 illustrates a flow diagram of a method 600 for providing secure CAN communications between a transmitter and a receiver, according to one or more exemplary embodiments. The method may be performed by at least one processing unit (e.g., processing unit 420) of a receiver (e.g., receiver 320) executing computer-readable instructions stored in one or more memory storages (e.g., memory 430, storage unit 440, etc.). Method 600 may be triggered whenever the receiver receives an appended message from a transmitter. The transmitter may be a first ECU, and the receiver may be a second ECU communicatively coupled to the first ECU via a CAN bus, for example. One or more operations of method 600 may be performed after one or more operations of method 500.

[0064] 6, in operation S610, at least one processing unit of the receiver may be configured to receive the appended message from the transmitter via the CAN bus. Accordingly, in operation S620, the at least one processing unit of the receiver may generate another OTP in a manner similar to how the transmitter generates the OTP. Thereafter, in operation S630, the at least one processing unit of the receiver may obtain a master key, and then, in operation S640, the at least one processing unit of the receiver may derive another shared key based on the OTP (generated in operation S620) and the master key (obtained in operation S630).

[0065] The specific operations associated with deriving the shared key are described above with reference to Figures 2 and 3. Accordingly, redundant descriptions associated therewith may be omitted below for the sake of brevity.

[0066] Upon deriving another shared key, method 600 may proceed to operation S650, where at least one processing unit of the receiver may be configured to generate another MAC based on the another derived shared key. In some example implementations, the at least one processing unit of the receiver may generate another MAC based on the another derived shared key and a counter value.

[0067] According to an example embodiment, before deriving another MAC, at least one processing unit of the receiver may check whether the appended message includes a counter value and may check the counter value based on a determination that the appended message includes a counter value. For example, the at least one processing unit may obtain information about a previously received counter value and then compare the last received counter value with the counter value included in the appended message.

[0068] Based on a determination that the counter value in the appended message is greater than the previously received counter value, the at least one processing unit may determine that the newly received appended message is new and valid and may update the previously stored counter value with the newly received counter value included in the appended message. Accordingly, the at least one processing unit may calculate another MAC using the latest counter value (stored in the receiver's memory or provided by the receiver's monotonic counter) in addition to another derived shared key. For example, the at least one processing unit may truncate the counter value and the another derived shared key and then generate another MAC based on the truncated counter value and the truncated derived shared key.

[0069] On the other hand, based on a determination that the counter value in the appended message is less than or equal to the previously received counter value, the at least one processing unit may determine that the newly received appended message is stale or a potential replay attack, and therefore, the at least one processing unit may reject or discard the newly received appended message.

[0070] The specific operations associated with generating a MAC are described above with reference to Figure 3. Accordingly, redundant descriptions associated therewith may be omitted below for the sake of brevity.

[0071] Upon generating another MAC, method 600 may proceed to operation S660, where at least one processing unit of the receiver may be configured to authenticate the appended message based on the generated MAC. For example, the at least one processing unit may compare the generated MAC with the MAC included in the appended message to determine whether the generated MAC is the same as (or within a certain level of similarity with) the MAC included in the appended message. Based on a determination that the generated MAC is the same as (or within a certain level of similarity with) the MAC included in the appended message, the at least one processing unit of the receiver may determine that the appended message is authenticated. Otherwise, based on a determination that the generated MAC is different from (or not within a certain level of similarity with) the MAC included in the appended message, the at least one processing unit of the receiver may determine that the appended message is not authenticated.

[0072] Thereafter, at operation S670, at least one processing unit of the receiver may be configured to perform one or more operations to manage the appended message based on the validation of the appended message. For example, based on a determination that the appended message is validated, the at least one processing unit may extract a message from the appended message for further use (e.g., using the message to control various systems or components in the vehicle, logging information from the message for diagnostic purposes or historical record keeping, etc.). Conversely, based on a determination that the appended message is not validated, the at least one processing unit may reject or discard the appended message.

[0073] To this end, exemplary embodiments of the present disclosure provide secure CAN communications between ECUs (e.g., transmitter ECUs, etc.) and other vehicle components (e.g., receiver ECUs, sensors, etc.). Specifically, the shared key utilized in generating a MAC for message authentication is dynamically derived each time the ECU is powered on (when the vehicle first enters the IG-ON state). The shared key does not exist when the ECU is not powered on (when the vehicle is in the IG-OFF state), and the shared key changes each time the ECU is powered on (because the parameters used to derive the shared key change according to the time and geographic location of the vehicle). Thus, the risk of the shared key being compromised is significantly reduced, thereby improving the security of CAN communications between ECUs and other vehicle components.

[0074] It is assumed that the features, advantages, and significance of the exemplary embodiments described herein above are merely part of the present disclosure and are not intended to be exhaustive or to limit the scope of the present disclosure. A further description of the features, components, configuration, operation, and implementation aspects of the exemplary embodiments of the present disclosure, as well as associated technical advantages and significance, is provided below.

[0075] It is understood that the specific order or hierarchy of blocks in the processes / flowcharts disclosed herein is an example of an exemplary approach. Based on design preferences, it is understood that the specific order or hierarchy of blocks in the processes / flowcharts may be rearranged. Furthermore, some blocks may be combined or omitted. The accompanying method claims present elements of the various blocks in a sample order and are not meant to be limited to the specific order or hierarchy presented.

[0076] Some embodiments may relate to systems, methods, and / or computer-readable media at any possible level of technical detail of integration. Additionally, as described herein above, one or more of the above components described above may be implemented as instructions stored on a computer-readable medium and executable by at least one processor (and / or may include at least one processor). The computer-readable medium may include a computer-readable non-transitory storage medium(s) having computer-readable program instructions thereon for causing a processor to perform operations.

[0077] A computer-readable storage medium may be a tangible device that can hold and store instructions for use by an instruction-execution device. A computer-readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory sticks, floppy disks, mechanically encoded devices such as punch cards or ridge-in-groove structures having instructions recorded thereon, and any suitable combination thereof. As used herein, computer-readable storage media should not be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses passing through a fiber optic cable), or electrical signals transmitted over wires.

[0078] The computer-readable program instructions described herein may be downloaded to each computing / processing device from a computer-readable storage medium, or may be downloaded to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may include copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium in the respective computing / processing device.

[0079] The computer-readable program code / instructions for carrying out operations may be either assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or source or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, or the like, and procedural programming languages ​​such as the "C" programming language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection to the external computer may be made (e.g., through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) may execute computer-readable program instructions by utilizing state information of the computer-readable program instructions to personalize the electronic circuitry to perform aspects or operations.

[0080] The computer-readable program instructions may be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, executed by the processor of the computer or other programmable data processing apparatus, create means for implementing the function(s) / act(s) specified in the block(s) of the flowcharts and / or block diagrams. The computer-readable program instructions may also be stored on a computer-readable storage medium that can direct a computer, programmable data processing apparatus, and / or other device to function in a particular manner, such that the computer-readable storage medium having instructions stored therein comprises an article of manufacture including instructions that implement aspects of the function(s) / act(s) specified in the block(s) of the flowcharts and / or block diagrams.

[0081] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or another device to cause the computer, other programmable apparatus, or other device to perform a series of operational steps to create a computer-implemented process, such that the instructions executing on the computer, other programmable apparatus, or other device implement the function / act specified in the block or blocks of the flowcharts and / or block diagrams.

[0082] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer-readable media according to various embodiments. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions comprising one or more executable instructions for implementing a specified logical function. The methods, computer systems, and computer-readable media may include additional, fewer, different, or differently arranged blocks compared to those depicted in the figures. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may in fact be executed concurrently or substantially concurrently, or the blocks may even be executed in the reverse order, depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, may be implemented by dedicated hardware-based systems that perform the specified functions or acts or execute a combination of dedicated hardware and computer instructions.

[0083] It will be apparent that the systems and / or methods described herein may be implemented in various forms of hardware, firmware, or combinations of hardware and software. The actual dedicated control hardware or software code used to implement the systems and / or methods is not a limitation of the implementation. Thus, the operation and behavior of the systems and / or methods are described herein without reference to specific software code, and it will be understood that software and hardware can be designed to implement the systems and / or methods based on the description herein.

Claims

1. 1. A method for providing secure controller area network (CAN) communications between a transmitter and a receiver, the method comprising: generating, by at least one processing unit of the transmitter, a one-time passcode (OTP); obtaining, by the at least one processing unit of the transmitter, a master key previously provided to the transmitter and the receiver; deriving, by the at least one processing unit of the transmitter, a shared key based on the OTP and the master key; generating, by the at least one processing unit of the transmitter, a message authentication code (MAC) based on the derived shared key; adding, by the at least one processing unit of the transmitter, the MAC to a message; transmitting, by the at least one processing unit of the transmitter, the appended message to the receiver via a CAN bus; A method comprising:

2. The generation of the OTP comprises: obtaining, by the at least one processing unit of the transmitter, a master seed previously provided to the transmitter and the receiver; obtaining, by the at least one processing unit of the transmitter, a timestamp; obtaining, by the at least one processing unit of the transmitter, a geographic location of a vehicle in which the transmitter is deployed; generating, by the at least one processing unit of the transmitter, the OTP based on the master seed, the timestamp, and the geographic location; The method of claim 1 , comprising:

3. 3. The method of claim 1 or 2, wherein the transmitter is a first electronic control unit (ECU) and the receiver is a second ECU.

4. 3. The method of claim 2, wherein the timestamp is associated with timing information of the vehicle changing from an ignition-off (IG-OFF) state to an ignition-on (IG-ON) state, and the derived shared key comprises a unique random number that changes each time the vehicle enters the IG-ON state from the IG-OFF state.

5. The generation of the OTP comprises: truncating, by the at least one processing unit of the transmitter, the timestamp according to a tolerance level; generating, by the at least one processing unit of the transmitter, the OTP based on the master seed, the truncated timestamp, and the geographic location; The method of claim 2 or 4, further comprising:

6. The method of claim 1 or 2, wherein the message comprises a protocol data unit (PDU).

7. The generation of the MAC comprises: obtaining, by the at least one processing unit of the transmitter, a counter value; generating, by the at least one processing unit of the transmitter, the MAC based on the derived shared key and the counter value; Including, The attachment of the MAC to the message comprises: truncating, by the at least one processing unit of the transmitter, the counter value and the MAC; appending, by the at least one processing unit of the transmitter, the truncated MAC and the truncated counter value to the message; 3. The method of claim 1 or 2, comprising:

8. receiving, by the at least one processing unit of the receiver, the appended message from the transmitter via the CAN bus; generating another OTP by the at least one processing unit of the receiver; obtaining, by the at least one processing unit of the receiver, the master key previously provided to the transmitter and the receiver; deriving, by the at least one processing unit of the receiver, another shared key based on the another OTP and the master key; generating, by the at least one processing unit of the receiver, another MAC based on the another derived shared key; verifying, by the at least one processing unit of the receiver, the appended message based on the additional MAC; performing, by the at least one processing unit of the receiver, one or more operations to manage the appended message based on the verification of the appended message; The method of claim 1 or 2, further comprising:

9. The confirmation of the added message is determining, by the at least one processing unit of the receiver, whether the other MAC is the same as the MAC included in the appended message; determining, by the at least one processing unit of the receiver, that the appended message is authenticated based on a determination that the other MAC is the same as the MAC in the appended message; determining, by the at least one processing unit of the receiver, that the appended message is not authenticated based on a determination that the other MAC is different from the MAC in the appended message; The method of claim 8, comprising:

10. said performing said one or more actions further comprising: extracting the message from the appended message for further use by the at least one processing unit of the receiver based on a determination that the appended message is authenticated; and discarding, by the at least one processing unit of the receiver, the appended message based on a determination that the appended message is not authenticated; and 10. The method of claim 9, comprising:

11. 1. A system for providing secure controller area network (CAN) communications between a transmitter and a receiver, the system comprising: The transmitter includes: memory storage for storing computer-executable instructions; at least one processing unit communicatively connected to the memory storage; wherein the at least one processing unit executes the instructions to Generate a one-time passcode (OTP), Obtaining a master key previously provided to the transmitter and the receiver; deriving a shared key based on the OTP and the master key; generating a message authentication code (MAC) based on the derived shared key; appending said MAC to a message; and a system configured to transmit the appended message to the receiver via a CAN bus.

12. The at least one processing unit of the transmitter obtaining a master seed previously provided to the transmitter and the receiver; Obtaining a timestamp; obtaining a geographic location of a vehicle in which the transmitter is deployed; generating, by the at least one processing unit of the transmitter, the OTP based on the master seed, the timestamp, and the geographic location; The system of claim 11 , configured to generate the OTP by:

13. 13. The system of claim 11 or 12, wherein the transmitter is a first electronic control unit (ECU) and the receiver is a second ECU.

14. 13. The system of claim 12, wherein the timestamp is associated with timing information of the vehicle changing from an ignition-off (IG-OFF) state to an ignition-on (IG-ON) state, and the derived shared key comprises a unique random number that changes each time the vehicle enters the IG-ON state from the IG-OFF state.

15. The at least one processing unit of the transmitter further comprises: truncating the timestamp according to a tolerance level; generating the OTP based on the master seed, the truncated timestamp, and the geographic location; 15. The system of claim 12 or 14, configured to generate the OTP by

16. 13. The system of claim 11 or 12, wherein the message comprises a protocol data unit (PDU).

17. The at least one processing unit of the transmitter Obtaining a counter value; generating the MAC based on the derived shared key and the counter value; and configured to generate the MAC by The at least one processing unit of the transmitter truncating the counter value and the MAC; appending the truncated MAC and the truncated counter value to the message; 13. The system of claim 11 or 12, configured to append the MAC to the message by

18. The receiver further comprises: memory storage for storing computer-executable instructions; at least one processing unit communicatively connected to the memory storage; wherein the at least one processing unit executes the instructions to receiving the appended message from the transmitter via the CAN bus; Generate another OTP, Obtaining the master key previously provided to the transmitter and the receiver; deriving another shared key based on the another OTP and the master key; generating another MAC based on the other derived shared key; Validating the appended message based on the additional MAC; 13. The system of claim 11 or 12, configured to perform one or more actions to manage the appended message based on the corroboration of the appended message.

19. The at least one processing unit of the receiver determining whether the other MAC is the same as the MAC included in the appended message; determining that the appended message is authenticated based on a determination that the other MAC is the same as the MAC in the appended message; determining that the appended message is not authenticated based on a determination that the other MAC is different from the MAC in the appended message; 20. The system of claim 18, configured to validate the appended message by:

20. The at least one processing unit of the receiver extracting the message from the appended message for further use based on a determination that the appended message is authenticated; and discarding the appended message based on a determination that the appended message is not authenticated; and 20. The system of claim 19, configured to perform the one or more actions by:

Images