System and method for providing secure can communication

Abstract

The present disclosure provides systems and methods for providing secure CAN communications. Exemplary embodiments of the present disclosure provide secure CAN communication between vehicle components. According to an embodiment, a method for providing may include: generating, by at least one processing unit of a transmitter, a one-time password (OTP); acquiring, by at least one processing unit of the transmitter, a master key provided in advance to the transmitter and the receiver; deriving, by at least one processing unit of the transmitter, a shared key based on the OTP and the master key; generating, by at least one processing unit of the transmitter, a message authentication code (MAC) based on the derived shared key; attaching, by at least one processing unit of the transmitter, the MAC to the message; and transmitting the attached message to the receiver via the CAN bus by at least one processing unit of the transmitter.

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 Art

[0002] In the automotive industry, electronic control units (ECUs) are widely used as embedded systems for controlling various functions within the vehicle and its related systems. These functions may include, for example, engine management, transmission control, stability control, powertrain control, airbag control, and similar functions. Typically, the operation of an ECU involves data exchange and communication between the ECU and other vehicle components (e.g., other ECUs, sensors, actuators, etc.). This data exchange and communication is implemented via one or more buses, such as the CAN bus, Ethernet bus, and similar buses. In particular, the CAN bus offers a high degree of reliability, allowing multiple ECUs and devices to communicate with each other in real time, and is therefore widely used.

[0003] In order 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 and efficient communication between ECUs and vehicle components, authentication, confidentiality and integrity are not considered in the design and implementation of the relevant protocols, so it is not secure by design. In related technologies, in order to improve the security of CAN bus communication, some security mechanisms have been introduced for authentication and integrity protection. For example, the AUTOSAR (AUTomotive Open System ARchitecture) provides a secure onboard communication (SecOC) module to ensure secure communication between ECUs on the CAN bus network, thereby ensuring that the data received by the ECU is generated by the correct ECU and has the correct value.

[0004] Reference Figure 1 , Figure 1 FIG. 1 is a diagram showing an exemplary implementation of a SecOC module in the related art. Figure 1 In the example of , the transmitter 110 is configured to communicate with the receiver 120 by sending a protocol data unit (PDU) 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 key.

[0005] Before sending the PDU to the receiver 120, the transmitter 110 uses a shared key to calculate a message authentication code (MAC), and then appends or attaches the MAC information to the PDU to make a secure PDU. Therefore, the secure PDU is sent to the receiver 120, for example, via the CAN bus. The receiver 120 receives the secure PDU and uses the same shared key to calculate other MACs. Therefore, the receiver 120 can use the other MACs to verify the secure PDU. For example, when the MAC calculated by the receiver 120 is consistent with the MAC included in or attached to the secure PDU, the receiver 120 can determine that the secure PDU is sent by a reliable transmitter and has not been tampered with, and then the PDU can be further used. Otherwise, the receiver 120 can determine that the MAC verification has failed, and then the received PDU can be rejected or discarded.

[0006] The implementation of the SecOC module described above requires the pre-provisioning and sharing of static keys between ECUs. Although hardware security modules (HSMs) have been introduced to ensure the security of static shared keys, pre-provisioning of keys is still necessary for ECUs that lack HSMs in certain situations, thus creating the risk of key leakage.

[0007] In this regard, because the shared secret key is static between ECUs, even a single leak of the shared secret key can allow an attacker to compromise all associated ECUs. For example, using the leaked secret key, an attacker could perform a CAN injection attack, injecting or sending spoofed or forged signals to manipulate the information processed by the target ECU. This could allow an attacker to control critical safety functions of the target vehicle, such as disabling the vehicle's brakes, triggering airbag deployment, causing vehicle components to generate erroneous measurements, and similar functions.

[0008] In view of at least the foregoing 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 matching the present disclosure provide methods, systems, and apparatus for dynamically deriving a shared key that does not exist when the vehicle is in an ignition-off (IG-OFF) state and changes each time the vehicle enters an ignition-on (IG-ON) 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 a one-time password (OTP) by at least one processing unit of the transmitter; obtaining a master key that is pre-provided to the transmitter and the receiver by at least one processing unit of the transmitter; deriving a shared key based on the OTP and the master key by at least one processing unit of the transmitter; generating a message authentication code (MAC) based on the derived shared key by at least one processing unit of the transmitter; appending the MAC to a message by at least one processing unit of the transmitter; and sending the appended message to the receiver via a CAN bus by at least one processing unit of the transmitter.

[0011] According to an embodiment, a system for providing secure CAN communication between a transmitter and a receiver is provided. The system may include a transmitter comprising: a storage device configured to store computer-executable instructions; and at least one processing unit communicatively coupled to the storage device. The at least one processing unit may be configured to: generate a one-time password (OTP); obtain a master key pre-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 the CAN bus.

[0012] Additional aspects are described in part in the description that follows and may be apparent in part from the description, or may be achieved by practice of the embodiments presented in the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] The functions, advantages, and significance of preferred embodiments of the present disclosure will be described below with reference to the accompanying drawings, in which like reference numerals represent like elements.

[0014] Figure 1 A diagram showing an exemplary implementation of a SecOC module in the related art.

[0015] Figure 2 A diagram illustrating exemplary actions for dynamically deriving a shared key according to one or more exemplary embodiments.

[0016] Figure 3 A diagram illustrating an exemplary implementation of a SecOC module according to one or more exemplary embodiments.

[0017] Figure 4 A block diagram illustrating exemplary components of an ECU according to one or more exemplary embodiments.

[0018] Figure 5 A flow chart illustrating an exemplary method for providing secure CAN communication between a transmitter and a receiver.

[0019] Figure 6 A flow chart illustrating an exemplary method for providing secure CAN communication between a transmitter and a receiver. DETAILED DESCRIPTION

[0020] The following detailed description of the preferred embodiments refers to the accompanying drawings. The above disclosure provides examples and illustrations, but is not intended to be exhaustive or to limit the implementation scheme to the exact form disclosed. Modifications and variations can be obtained in view of the above disclosure or can be obtained from the implementation of the implementation scheme. Moreover, one or more functions or components of one embodiment can be embedded in other embodiments (or one or more functions of other embodiments) or can be combined with other embodiments (or one or more functions of other embodiments). Moreover, it will be understood that in the flowcharts and descriptions of the actions provided below, one or more actions can be omitted, one or more actions can be added, one or more actions can be (at least partially) implemented simultaneously, and the order of one or more actions can be switched.

[0021] Even if a particular combination of functions is recited in the claims and / or disclosed in this specification, that combination is not intended to limit the disclosure of possible implementations. Indeed, many of the functions may be combined in ways not specifically recited in the claims and / or disclosed in this specification. Each of the dependent claims listed below may be directly dependent on only one claim, but the disclosure of possible implementations includes each dependent claim in combination with all other claims in the claim set.

[0022] As long as it is not particularly clearly stated, the elements, behaviors or instructions used in this specification should not be interpreted as important (critical) or necessary (essential). In addition, when used in this specification, the articles "a" and "an" are intended to include more than one project and can be used in a manner that can be exchanged with "more than one". In the case of referring to only one project, the term "one" or the same term is used. In addition, when used in this specification, the terms "has", "have", "having", "include", "including" or similar terms refer to open terms. Moreover, unless otherwise specifically stated, the phrase "based on..." is intended to mean "at least partially based on...". Moreover, expressions 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 only A, only B or both A and B.

[0023] References throughout this specification to "one embodiment," "an embodiment," "a non-limiting preferred embodiment," or similar terms mean that a particular feature, structure, or characteristic described in connection with the illustrated embodiment is included in at least one embodiment of the present solution. Thus, the phrases "in one embodiment," "in an embodiment," "in a non-limiting preferred embodiment," and similar terms throughout this specification may all refer to the same embodiment, but not necessarily.

[0024] Furthermore, the functions, advantages, and features described in the present disclosure may be combined in any appropriate manner in one or more exemplary embodiments. In view of the description of this specification, those skilled in the art will recognize that the present disclosure may be implemented without one or more of the specific functions or advantages of a particular embodiment. In other examples, additional functions and advantages may be recognized in a particular embodiment that is sometimes not present in all embodiments of the present disclosure.

[0025] Furthermore, the term "vehicle" as used herein refers to any suitable type of vehicle capable of implementing the exemplary embodiments of the present disclosure. For example, a "vehicle" may refer to a powered vehicle, such as a passenger car, truck, bus, motorcycle, or any other suitable type of automobile powered by an engine, motor, or other mechanical unit. Alternatively or in addition, a "vehicle" as used herein may refer to a bicycle, skateboard, or any other suitable type of unpowered vehicle without departing from the scope of the present disclosure.

[0026] In addition, the exemplary embodiments of the present disclosure are described in this specification with reference to communication between ECUs, but it can be assumed that the exemplary embodiments can also be applied to provide secure communication between other vehicle components, for example, between the ECU and onboard sensors, between the ECU and actuators, between onboard sensors and actuators, and between similar components, without departing from the scope of the present disclosure.

[0027] The systems and methods of the related art such as those described above require a static shared key to be pre-provisioned in the ECU, with the result that the ECU can use the static shared key to generate a MAC, and then verify the communication message from the perspective of reliability and integrity based on the MAC. On the other hand, the exemplary embodiment of the present disclosure does not require a static shared key to be pre-provisioned in the ECU. On the contrary, the exemplary embodiment of the present disclosure utilizes variable parameters to derive symmetric keys, for example, based on the vehicle state. For example, each ECU that communicates with other vehicle components (e.g., other ECUs, sensors, actuators, etc.) via the CAN bus can derive the same key when the vehicle changes from the ignition off (IG-OFF) state to the ignition on (IG-ON) state (e.g., when the vehicle is initially started), and then the derived shared key can be used to secure communications between the ECUs. The shared key does not exist when the vehicle is in the IG-OFF state, and the shared key is dynamically derived when the vehicle is started, and is different each time the vehicle enters the IG-ON state. The following reference Figure 2 Described are exemplary actions associated with derivation of a key according to one or more exemplary embodiments.

[0028] Figure 2 A diagram illustrating exemplary actions for dynamically deriving a shared key according to one or more exemplary embodiments. Figure 2 The cryptographic generator 210 and the key derivation module 220 in the embodiment may be implemented as functional modules of the ECU and may be implemented in various forms such as hardware, firmware, or a combination of hardware and software. In this regard, it is assumed that when the software or computer-executable instructions for implementing the cryptographic generator 210 and the key derivation module 220 are executed, one or more actions described in this specification with reference to the cryptographic generator 210 and the key derivation module 220 may be implemented by hardware (e.g., a processing unit, etc.).

[0029] The password generator 210 can be configured to generate one or more one-time passwords (OTPs) and then provide the generated one or more OTPs to the key derivation module 220 for further processing. OTP generation can be initiated or triggered based on the vehicle's state. For example, when the vehicle changes from the IG-OFF state to the IG-ON state, the ECU can always be powered on, and OTP generation can be automatically initiated in each ECU that needs to authenticate communication with other vehicle components via a message authentication code (MAC).

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

[0031] The timestamp 211 may be associated with the timing when the vehicle changes from the IG-OFF state to the IG-ON state (e.g., when the vehicle is initially started). The password generator 210 may obtain the timestamp information from the ECU's internal clock. Here, the internal clock may be configured to record and provide timestamp information associated with the vehicle state (e.g., when the vehicle initially enters the IG-ON state, when the vehicle is parked, etc.).

[0032] According to an exemplary embodiment, upon receiving a timestamp, cryptographic generator 210 may truncate the timestamp according to a tolerance level. For example, based on a given tolerance level, cryptographic generator 210 may discard the millisecond component of the timestamp to achieve a tolerance level related to seconds, round the timestamp to the nearest whole second, and perform similar processing. In this way, as long as the timestamp falls within the tolerance level, each ECU can generate the same OTP (and, therefore, derive the same key).

[0033] Geographic location 212 can be associated with the vehicle's latitude and longitude coordinates (or other location and / or position data) when the vehicle enters the IG-ON state (for ECU deployment). Cryptography generator 210 can obtain geographic location information through various means, such as global positioning system (GPS) collaboration, inertial navigation system (INS) measurement, cellular network or Wi-Fi triangulation, and similar means.

[0034] The master seed 213 may comprise a set of values ​​securely stored within the ECU's memory or firmware. The master seed may be pre-provisioned to the ECU by the vehicle manufacturer or system administrator during the ECU's manufacturing or initialization process. Access to and utilization of the master seed is limited to the cryptographic generator 210.

[0035] Upon obtaining the timestamp 211, geographic location 212, and master seed 213, the cryptographic generator 210 may combine this information or data to generate one or more OTPs. For example, the cryptographic generator 210 may perform one or more actions, such as concatenation, cryptographic hashing, cryptographic signing, and similar actions, to generate one or more OTPs based on the timestamp, geographic location, and master seed. Therefore, when the vehicle transitions from an IG-OFF state to an IG-ON state, the timestamp and / or geographic location of the vehicle constantly change. Therefore, the cryptographic generator 210 may generate and provide a unique dynamic OTP to the key derivation module 220 to derive one or more unique dynamic shared keys.

[0036] The key derivation module 220 may be configured to obtain one or more OTPs and a master key 230 (from the cryptographic generator 210), and then, based thereon, derive a shared key 240. The master key 230 may include a secret encryption key used as a basis for deriving the shared key 240, and may be pre-provisioned to each ECU during the manufacturing or initialization process.

[0037] The key derivation module 220 combines a unique OTP (provided by the cryptographic generator 210) with the master key 230 to derive a unique shared key 240. The key derivation module 220 can implement one or more cryptographic algorithms, such as a key derivation function (KDF), a hash-based function (e.g., SHA-256, SHA-512, etc.), or similar algorithms, to derive the shared key 240 based on the OTP and the master key 230. Similar to OTP generation, shared key derivation can also be initiated or triggered based on the vehicle's state. For example, if the vehicle's ECU remains powered on when the vehicle transitions from IG-OFF to IG-ON, shared key derivation can be automatically initiated in each ECU after the OTP is generated.

[0038] assumed Figure 2 The illustrated configuration is merely one possible configuration, and actual implementations of the exemplary embodiment are not limited thereto. Specifically, in some implementations, multiple master seeds 213 and / or multiple master keys 230 may be associated with the process of deriving a shared key 240, and timestamp 211 may be obtained from a component external to the ECU. Similar situations may exist without departing from the disclosure of this invention.

[0039] Considering the above, exemplary embodiments of the present disclosure can provide a unique dynamic shared key each time a vehicle transitions from an IG-OFF state to an IG-ON state, for example. This 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, compared to the use of pre-provided static shared keys in related art, the risk of shared key leakage can be significantly reduced.

[0040] Next, refer to Figure 3 Describe one or more exemplary embodiments of implementing the derived shared key. Specifically, Figure 3 A diagram illustrating an exemplary implementation of a SecOC module according to one or more exemplary embodiments.

[0041] exist Figure 3 In the example of FIG, the transmitter 310 is configured to communicate with the receiver 320 by sending a protocol data unit (PDU). The transmitter 310 and the receiver 320 can each be an ECU, and each can include (refer to FIG Figure 2 By effectively utilizing the password generator and key derivation module, the transmitter 310 and the receiver 320 can each generate a unique shared key when they are first powered on (when the vehicle first enters the IG-ON state). For detailed instructions on the derivation of the shared key, see Figure 2 It has been explained above, and therefore, redundant explanations related thereto may be omitted for simplicity.

[0042] Used to secure PDUs via MAC generation and MAC verification Figure 3 The general actions in Figure 1 The actions recorded are the same. Figure 3 and Figure 1 The difference between the implementation schemes is that Figure 1 The shared key in is static and is pre-provided to the sender and receiver, while Figure 3 The shared key in is dynamically generated by the transmitter and receiver when the transmitter and receiver are initially powered on. Figure 3 An optional monotonic counter is used to provide more than one counter value, with the result that the sender 310 and receiver 320 may use more than one counter value in addition to the derived shared key to secure the PDU.

[0043] Before sending the PDU to the receiver 320, the transmitter 310 uses the derived shared key (derived by the transmitter 310 when the transmitter 310 is initially powered on) to calculate a message authentication code (MAC), and then appends the MAC information to the PDU to make a secure PDU.

[0044] Optionally, the calculation of the MAC and the production of the secure PDU may be further accompanied by a counter value in addition to the derived shared key. Figure 3 In the example, sender 310 includes a monotonic counter that increases over time. When sender 310 sends a message on the network, it always provides a counter value associated with this monotonic counter. In this regard, the monotonic counters in sender 310 and receiver 320 can be synchronized during startup or communication initialization to ensure that both sender 310 and receiver 320 have consistent starting points for their monotonic counters, thereby preventing problems such as message rejection caused by large initial counter differences and similar reasons. The counter value can be used to provide freshness to the message, and therefore, in some implementations, the counter value can also be referred to as a "freshness value."

[0045] In the case of a counter value, the transmitter 310 may obtain the counter value from a monotonic counter and then generate a MAC based on the counter value and the derived shared key. Furthermore, the transmitter 310 may append both the counter value and the generated MAC to a message (e.g., a PDU) to create an appended message (e.g., a secure PDU).

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

[0047] When an attached message (e.g., a secure PDU) is generated, the transmitter 310 may, for example, send the attached message to the receiver 320 via the CAN bus. The receiver 320 receives the attached message and verifies the attached message before further utilizing the attached message. Specifically, the receiver 320 may use the derived shared key (derived by the receiver 320 when the receiver 320 is initially powered on) to calculate another MAC, which is then used to verify the attached message. For example, if the MAC calculated by the receiver 320 is consistent with the MAC included in or attached to the message, the receiver 320 may thereby determine that the attached message is authenticated and sent by a reliable sender / has not been tampered with, and may then extract the message from the attached message for further utilization. Otherwise, the receiver 320 may determine that the MAC verification failed and the attached message was not authenticated, and may then reject or discard the received message.

[0048] According to an exemplary embodiment in which the appended message includes a counter value, receiver 320 may also check the counter value included in the appended message upon receiving the appended message. For example, receiver 320 may obtain information about previously received counter values ​​and then compare the most recently 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 receiver 320 may update the previously stored counter value to the newly received counter value included in the appended message. Therefore, in addition to the derived shared key, receiver 320 may also use the latest counter value (stored in the memory of receiver 320 or provided by a monotonic counter of receiver 320) 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 old or a potential replay attack, and receiver 320 may reject or discard the newly received appended message.

[0049] Next, refer to Figure 4 , Figure 4 A block diagram illustrating exemplary components of an ECU 400 according to one or more exemplary embodiments is provided. ECU 400 may include one or more ECUs responsible for controlling various vehicle functions, such as engine management, transmission control, braking systems, and similar functions. In this regard, it is assumed throughout this specification that each of the aforementioned transmitter 310 and receiver 320 (as well as functional modules such as a cryptographic generator and key derivation module) and their associated operations can be implemented by ECU 400.

[0050] like Figure 4 As shown, the 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. Assume that the ECU 400 may include more than Figure 4 More or fewer components may be included than those shown without departing from the scope of the present disclosure. For example, in some embodiments, the ECU 400 may include multiple storage units 440, the input unit 450 and the output unit 460 may be implemented as transceiver components, and the memory 430 and the storage unit 440 may be implemented as storage devices, and similar situations may exist.

[0051] The bus 410 can be configured to facilitate or enable communication between components of the ECU 400. Specifically, the bus 410 can connect the components in a manner that allows them to communicate with each other, providing a means for data movement and flow of control signals between the components. The bus 410 can 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 can be implemented in the ECU 400 to enable communication and coordination between components within the ECU 400.

[0052] The processing unit 420 can be implemented using hardware, firmware, or a combination of hardware and software, and can be configured to handle real-time (or substantially real-time) data processing and control of the ECU 400. The processing unit 420 can 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 a chip (SoC), a central processing unit (CPU), a graphics processing unit (GPU), or any other suitable type of processing unit that can be implemented in the ECU 400. In some implementations, the processing unit 420 can be programmed to perform one or more of the operations described herein. Furthermore, the processing unit 420 can include multiple processing units, each dedicated to performing a specific operation (e.g., a processing unit can be assigned to perform operations of the cipher generator, another processing unit can be assigned to perform operations of the key derivation module, etc.).

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

[0054] The storage unit 440 can be configured to store non-volatile data, such as firmware, configuration settings, calibration data, and other persistent information required for the operation of the ECU. For example, the storage unit 440 can store one or more counter values, one or more pre-provided master seeds, one or more pre-provided master keys, one or more established tolerance levels, and similar data. In addition, the storage unit 440 can also store computer-readable instructions or computer-executable instructions for implementing one or more actions described in this specification. The storage unit 440 can provide the stored information to the memory 430 for execution by the processor 420. The storage unit 440 can include one or more of flash memory, read-only memory (ROM), solid-state storage media, and any other appropriate type of storage component that can be implemented in the ECU 400.

[0055] The input unit 450 may include one or more external vehicle components, such as one or more input components that enable the ECU 400 to receive information from one or more sensors (e.g., an engine sensor that provides signals regarding the IG-OFF state and the IG-ON state), one or more positioning systems (e.g., a Global Positioning System (GPS), an Inertial Navigation System (INS), etc.) that provide geographic location information of the vehicle in which the ECU 400 is deployed, a timing device that provides timestamp information (e.g., an internal clock, a real-time clock (RTC), etc.), a counter that provides a counter value (e.g., a monotonic counter), and similar devices. Furthermore, the input unit 450 may also include a component that enables the ECU 400 to receive one or more user inputs (e.g., user input for providing updates to the master seed and master key, etc.). According to an exemplary embodiment, the input portion 450 may include a local interconnect network (LIN) receiver, a CAN bus receiver, a CAN transceiver, a FlexRay transceiver, a wireless transceiver, and similar devices that enable the ECU 400 to receive messages or data from other vehicle components (e.g., other ECUs, etc.).

[0056] Output unit 460 may include one or more external components, for example, one or more output components that enable ECU 400 to provide information to one or more sensors and similar devices. Furthermore, output unit 460 may also include components that enable ECU 400 to output information (e.g., determination of unverified messages, etc.) to one or more users. According to an exemplary embodiment, output unit 460 may include a LIN transmitter, a CAN bus transmitter, a CAN transceiver, a FlexRay transceiver, a wireless transceiver, or similar devices that enable ECU 400 to transmit messages or data to other vehicle components (e.g., other ECUs, etc.).

[0057] Communication interface 470 may include one or more interfaces that facilitate communication between components of ECU 400 and one or more external vehicle components. For example, communication interface 470 may facilitate the exchange of messages or data between ECU 400 and other ECUs, between ECU 400 and sensors / actuators, and between similar components. According to an exemplary embodiment, communication interface 470 may include a CAN controller interface that manages the transmission and reception of messages by ECU 400 via a CAN bus. Furthermore, 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 other ECUs, etc.).

[0058] In response to at least one processing unit 420 executing one or more computer-executable instructions for implementing the actions described in this specification, ECU 400 can implement one or more actions described in this specification. The computer-executable instructions can be stored by a non-transitory computer-readable recording medium such as memory 430 and / or storage unit 440. Computer-readable media is defined in this specification as a non-transitory storage device. A storage device can include memory space within a single physical storage device or memory space across multiple physical storage devices.

[0059] Computer-executable instructions (e.g., software instructions, etc.) can be read into memory 430 and / or storage unit 440 from other computer-readable media or from other devices (e.g., remote servers, external storage, etc.) via communication interface 470. When executed, the computer-executable instructions stored in memory 430 and / or storage unit 440 can cause processing unit 420 to implement one or more processes described in this specification. Additionally or alternatively, hardwired circuitry can be used in place of or in combination with software instructions to implement one or more processes described in this specification. Therefore, the implementation scheme described in this specification is not limited to any specific combination of hardware circuitry and software.

[0060] Figure 5A flow chart illustrating a method 500 for providing secure CAN communication between a transmitter and a receiver, according to one or more exemplary embodiments, is provided. The method can be performed by at least one processing unit (e.g., processing unit 420) of a transmitter (e.g., transmitter 310) when executing computer-readable instructions stored in one or more storage devices (e.g., memory 430, storage portion 440, etc.). Method 500 can be triggered whenever the transmitter has a message to send to the receiver. The transmitter can be a first ECU, and the receiver can be a second ECU communicatively connected to the first ECU via, for example, a CAN bus.

[0061] like Figure 5 As shown, in action S510, at least one processing unit of the transmitter can be configured to generate a one-time password (OTP). Specifically, the at least one processing unit can obtain a master seed that is pre-provided to the transmitter and receiver (e.g., from a storage device), obtain a timestamp (e.g., from an internal clock), and obtain the geographic location of the vehicle deployed by the transmitter (e.g., from a location system). Therefore, the at least one processing unit can generate the OTP based on the master seed, the timestamp, and the geographic location. According to an exemplary embodiment, the at least one processing unit can 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.

[0062] In action S520, at least one processing unit of the transmitter can be configured to obtain a master key. The master key can be pre-provided to the transmitter and the receiver and can be stored in a storage device of the transmitter and the receiver. It is assumed that actions S510 and S520 can be performed in any suitable order (e.g., action S520 can be performed simultaneously with action S510, action S520 can be performed before action S510, etc.) without departing from the scope of this disclosure.

[0063] After receiving the master key, method 500 may proceed to act S530, where at least one processing unit of the transmitter may be configured to derive a shared key based on the OTP (generated in act S510) and the master key (obtained in act S520). According to an exemplary embodiment, a timestamp may be associated with timing information when the vehicle transitions 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 transitions from an IG-OFF state to an IG-ON state.

[0064] Refer to the specific actions related to the derivation of the shared key Figure 2 and Figure 3Therefore, redundant descriptions related thereto may be omitted below for simplicity.

[0065] After deriving the shared key, method 500 may proceed to act S540, in which 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 exemplary 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.

[0066] After generating the MAC, method 500 may proceed to act S550, where at least one processing unit of the transmitter may be configured to append the MAC to the message. The message may include a protocol data unit (PDU). According to an exemplary embodiment related to the 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.

[0067] After appending the MAC to the message, method 500 may proceed to act 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.

[0068] For specific actions related to MAC generation, MAC addition to messages, and message transmission after addition, refer to Figure 3 Therefore, redundant descriptions related thereto may be omitted below for simplicity.

[0069] Figure 6 A flowchart illustrating method 600 for providing secure CAN communication between a transmitter and a receiver, according to one or more exemplary embodiments, is provided. The method may be performed by at least one processing unit (e.g., processing unit 420) of a receiver (e.g., receiver 320) when executing computer-readable instructions stored in one or more storage devices (e.g., memory 430, storage portion 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 connected to the first ECU via, for example, a CAN bus. One or more actions of method 600 may be performed after one or more actions of method 500.

[0070] Reference Figure 6In action S610, at least one processing unit of the receiver may be configured to receive the appended message from the transmitter via the CAN bus. Thus, in action S620, at least one processing unit of the receiver may generate other OTPs using the same method as the OTP generated by the transmitter. Thereafter, in action S630, at least one processing unit of the receiver may obtain the master key. Subsequently, in action S640, at least one processing unit of the receiver may derive other shared keys based on the OTP (generated in action S620) and the master key (obtained in action S630).

[0071] Refer to the specific actions related to the derivation of the shared key Figure 2 and Figure 3 Therefore, redundant descriptions related thereto may be omitted below for simplicity.

[0072] After deriving the other shared key, method 600 may proceed to act S650, where at least one processing unit of the receiver may be configured to generate the other MAC based on the derived other shared key. In some exemplary implementations, at least one processing unit of the receiver may generate the other MAC based on the derived other shared key and a counter value.

[0073] According to an exemplary embodiment, before deriving the other MACs, at least one processing unit of the receiver may check whether the appended message includes a counter value. The counter value may be checked based on a determination that the appended message includes a counter value. For example, the at least one processing unit may obtain information about previously received counter values ​​and then compare the most recently received counter value with the counter value included in the appended message.

[0074] 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 can determine that the newly received appended message is new and valid, and can update the previously stored counter value to the newly received counter value included in the appended message. Thus, the at least one processing unit can utilize the latest counter value (stored in the receiver's memory or provided by a monotonic counter at the receiver) in addition to the derived other shared key to calculate the other MAC. For example, the at least one processing unit can truncate the counter value and the derived other shared key, and then generate the other MAC based on the truncated counter value and the truncated and derived shared key.

[0075] On the other hand, based on the 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 old or a potential replay attack. Therefore, the at least one processing unit may reject or discard the newly received appended message.

[0076] Specific actions related to MAC generation refer to Figure 3 Therefore, redundant descriptions related thereto may be omitted below for simplicity.

[0077] After generating the other MAC, method 600 can proceed to action S660, in which at least one processing unit of the receiver can be configured to verify the appended message based on the generated MAC. For example, the at least one processing unit can 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) 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) the MAC included in the appended message, the at least one processing unit of the receiver can determine that the appended message is verified. Otherwise, based on a determination that the generated MAC is different from (or not within a certain level of similarity) the MAC included in the appended message, the at least one processing unit of the receiver can determine that the appended message is not verified.

[0078] Thereafter, in action S670, at least one processing unit of the receiver may be configured to perform one or more actions to manage the attached message based on the verification of the attached message. For example, based on a determination that the attached message is verified, at least one processing unit may extract information from the attached message for further use (e.g., using the message to control various systems or components within the vehicle, logging information from the message for diagnostic purposes or historical record maintenance, etc.). Conversely, based on a determination that the attached message is not verified, at least one processing unit may reject or discard the attached message.

[0079] To this end, an exemplary embodiment of the present disclosure provides secure CAN communication between ECUs (e.g., transmitter ECUs, etc.) and other vehicle components (e.g., receiver ECUs, sensors, etc.). Specifically, each time the ECU is powered on (when the vehicle initially enters the IG-ON state), a shared key is dynamically derived for use in generating a MAC for message authentication. The shared key does not exist when the ECU is not powered on (when the vehicle is in the IG-OFF state), and each time the ECU is powered on, the shared key changes (because the parameters used to derive the shared key change with the time and geographical location of the vehicle). Therefore, the risk of the shared key being leaked is significantly reduced, thereby improving the security of CAN communication between the ECU and other vehicle components.

[0080] It is assumed that the functions, advantages, and significance of the exemplary embodiments described above in this specification are only part of the present disclosure and are not intended to be exhaustive or limit the scope of the present disclosure. Further description of the functions, components, configurations, actions, and implementation schemes of the exemplary embodiments of the present disclosure and the advantages and significance of the associated technologies will be provided below.

[0081] It is understood that the specific order or hierarchy of the functional blocks in the process / flowchart disclosed in this specification is an example of an exemplary method. It is understood that the specific order or hierarchy of the functional blocks in the process / flowchart can be reconfigured based on design preferences. Moreover, some functional blocks can be combined or some functional blocks can be omitted. The attached method claims present the elements of various functional blocks in an exemplary order, which does not mean that the elements of various functional blocks are limited to the specific order or hierarchy presented.

[0082] Some embodiments may involve systems, methods, and / or computer-readable media at any possible level of technical detail of the integration. Moreover, as described above in this specification, one or more of the above-mentioned components may be implemented as instructions stored in 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 (or multiple media) having computer-readable program instructions therein to cause the processor to perform actions.

[0083] 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, 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, but is not limited thereto. A non-exhaustive list of more specific examples of computer-readable storage media includes the following, namely, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disc (DVD), a memory stick, a floppy disk, a punch card with instructions recorded on it, or a mechanically encoded device such as a raised structure in a slot, and any suitable combination thereof. The computer-readable storage medium used in this specification should not be interpreted as a temporary signal itself, such as an electric wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (for example, a light pulse passing through an optical cable), or an electrical signal transmitted through a wire.

[0084] The computer-readable program instructions described in this specification can be downloaded from a computer-readable storage medium to each computing / processing device, or can 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 can include copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface within each computing / processing device receives the computer-readable program instructions from the network and transmits the computer-readable program instructions to be stored on a computer-readable storage medium within the computing / processing device.

[0085] The computer readable program code / instructions for performing the actions may be any of assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state setting data, configuration data for an integrated circuit, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, or similar programming languages, 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 stand-alone 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 case, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, for example, an electronic circuit including a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) can utilize state information of computer-readable program instructions to personalize the electronic circuit, thereby executing the computer-readable program instructions to implement an embodiment or action.

[0086] The computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to generate a machine. As a result, the instructions executed by the processor of the computer or other programmable data processing device produce a unit for implementing the functions / behaviors specified by the functional block or multiple functional blocks in the flowchart and / or block diagram. The computer-readable program instructions can also be stored in a computer-readable storage medium that can instruct a computer, programmable data processing device, and / or other device to perform functions in a specific method. As a result, the computer-readable storage medium having the instructions stored therein has a product including instructions for implementing the scheme for implementing the functions / behaviors specified by the functional block or multiple functional blocks in the flowchart and / or block diagram.

[0087] Computer-readable program instructions can also be loaded into a computer, other programmable data processing apparatus or other device to cause a series of action steps to be performed on the computer, other programmable apparatus or other device, thereby generating a computer-implemented process, as a result of which the instructions executed on the computer, other programmable apparatus or other device implement the functions / behaviors specified in the functional box or multiple functional boxes in the flowchart and / or block diagram.

[0088] The flowcharts and block diagrams in the accompanying drawings represent the architecture, functions and actions of possible implementation schemes of the systems, methods and computer-readable media of various embodiments. In this regard, each functional block in the flowchart or block diagram can represent a module, a program segment or a portion of an instruction, which has one or more executable instructions for implementing the specified logical function. The method, computer system and computer-readable medium can include additional functional blocks, fewer functional blocks, different functional blocks or functional blocks of different configurations compared to the functional blocks depicted in the accompanying drawings. In a partially replaced implementation scheme, the functions recorded in the functional blocks can occur independently of the order recorded in the accompanying drawings. For example, two functional blocks shown in succession can actually be executed simultaneously or substantially simultaneously, or the functional blocks can sometimes be executed in reverse order according to the related functions. It should also be noted that the functional blocks of the block diagram and / or flowchart and the combination of the functional blocks of the block diagram and / or flowchart can be implemented by a system based on dedicated hardware, which implements the specified function or behavior, or executes a combination of dedicated hardware and computer instructions.

[0089] It is apparent that the systems and / or methods described in this specification can be implemented in various forms of hardware, firmware, or a combination of hardware and software. The actual dedicated control hardware or software code used to implement the system and / or method does not limit the implementation scheme. Therefore, it is understood that the actions and behaviors of the system and / or method are described in this specification without reference to specific software code, and software and hardware can be designed to implement the system and / or method based on the description of this specification.

Claims

1. A method for providing secure Controller Area Network (CAN) communication between a transmitter and a receiver, the method comprising: generating a one-time password (OTP) by at least one processing unit of the transmitter; obtaining, by the at least one processing unit of the sender, a master key that is pre-provided to the sender 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; as well as The appended message is sent to the receiver via a CAN bus by the at least one processing unit of the transmitter.

2. The method according to claim 1, wherein The generating of the OTP comprises: obtaining, by the at least one processing unit of the transmitter, a master seed that is pre-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 geographical location of a vehicle at which the transmitter is deployed; and The OTP is generated, by the at least one processing unit of the transmitter, based on the master seed, the timestamp, and the geographical location.

3. The method according to claim 1 or 2, wherein: The transmitter is a first electronic control unit ECU, and the receiver is a second ECU.

4. The method according to claim 2, wherein: The timestamp is associated with timing information of the vehicle changing from an ignition-off state to an ignition-on state, and the derived shared key includes a unique random number that changes each time the vehicle changes from the IG-off state to the IG-on state.

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

6. The method according to any one of claims 1 to 5, wherein The message includes a protocol data unit (PDU).

7. The method according to any one of claims 1 to 6, wherein The generating of the MAC comprises: obtaining, by the at least one processing unit of the transmitter, a counter value; and generating, by the at least one processing unit of the transmitter, the MAC based on the derived shared key and the counter value, The appending of the MAC to the message comprises: truncating, by the at least one processing unit of the transmitter, the counter value and the MAC; and The truncated MAC and the truncated counter value are appended to the message by the at least one processing unit of the transmitter.

8. The method according to any one of claims 1 to 7, further comprising: receiving, by the at least one processing unit of the receiver, the appended message from the transmitter via the CAN bus; generating, by the at least one processing unit of the receiver, a further OTP; obtaining, by the at least one processing unit of the receiver, the master key that is pre-provided to the sender and the receiver; deriving, by the at least one processing unit of the receiver, another shared key based on the other OTP and the master key; generating, by the at least one processing unit of the receiver, another MAC based on the derived other shared key; verifying, by the at least one processing unit of the receiver, the appended message based on the other MAC; as well as One or more actions are performed, by the at least one processing unit of the receiver, to manage the appended message based on the verification of the appended message.

9. The method according to claim 8, wherein The verification of the appended message comprises: 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; 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 authenticated; and Based on a determination that the other MAC is different from the MAC in the appended message, a determination is made by the at least one processing unit of the receiver that the appended message is not authenticated.

10. The method according to claim 9, wherein: The implementation of the one or more actions includes: extracting, by the at least one processing unit of the receiver, the message from the appended message for further utilization based on a determination that the appended message is authenticated; and Based on a determination that the appended message is not authenticated, the appended message is discarded by the at least one processing unit of the receiver.

11. A system for providing secure Controller Area Network (CAN) communication, comprising: a system for providing secure CAN communication between a transmitter and a receiver, the system comprising the transmitter; The transmitter comprises: a storage memory storing computer-executable instructions; and at least one processing unit, connected to the storage device in a communicable manner, The at least one processing unit is configured to execute the instructions to perform the following steps: Generate a one-time password (OTP); Obtaining a master key that is pre-provided to the sender 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 the MAC to the message; as well as The appended message is sent to the receiver via a CAN bus.

12. The system according to claim 11, wherein The at least one processing unit of the transmitter is configured to generate the OTP by: Obtaining a master seed that is pre-provided to the transmitter and the receiver; Get timestamp; obtaining a geographic location of a vehicle for deployment of the transmitter; as well as The OTP is generated, by the at least one processing unit of the transmitter, based on the master seed, the timestamp, and the geographical location.

13. The system according to claim 11 or 12, wherein: The transmitter is a first electronic control unit ECU, and the receiver is a second ECU.

14. The system according to claim 12, wherein: The timestamp is associated with timing information of the vehicle changing from an ignition-off state to an ignition-on state, and the derived shared key includes a unique random number that changes each time the vehicle changes from the IG-off state to the IG-on state.

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

16. The system according to any one of claims 11 to 15, wherein: The message includes a protocol data unit (PDU).

17. The system according to any one of claims 11 to 16, wherein: The at least one processing unit of the transmitter is configured to generate the MAC by: Get the counter value; and generating the MAC based on the derived shared key and the counter value, The at least one processing unit of the transmitter is configured to append the MAC to the message by: truncating the counter value and the MAC; as well as The truncated MAC and the truncated counter value are appended to the message.

18. The system according to any one of claims 11 to 17, further comprising the receiver, The receiver comprises: a storage memory storing computer-executable instructions; and at least one processing unit, connected to the storage device in a communicable manner, The at least one processing unit is configured to execute the instructions to perform the following steps: receiving the appended message from the transmitter via the CAN bus; Generate other OTPs; obtaining the master key that is provided in advance to the sender and the receiver; deriving other shared keys based on the other OTPs and the master key; generating another MAC based on the derived other shared key; authenticating the appended message based on the other MAC; as well as One or more actions are performed to manage the appended message based on the verification of the appended message.

19. The system according to claim 18, wherein: The at least one processing unit of the receiver is configured to verify the appended message by: 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 identical to the MAC in the appended message; as well as Based on a determination that the other MAC is different from the MAC in the appended message, it is determined that the appended message is not authenticated.

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

Images