Secure communication over a can bus
Patent Information
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- STELLANTIS EUROPE SPA
- Filing Date
- 2026-01-20
- Publication Date
- 2026-08-06
Smart Images
Figure IB2026050501_06082026_PF_FP_ABST
Abstract
Description
[0001] SECURE COMMUNICATION OVER A CAN BUS
[0002] ****
[0003] TEXT OF THE DESCRIPTION
[0004] Field of the invention
[0005] Various embodiments of the present description concern solutions for improving security in communication systems based on Controller Area Network (CAN) networks.
[0006] Prior art
[0007] Most electrical and mechanical components of modern vehicles are controlled by interconnected Electronic Control Units (ECUs), which, together with sensors and actuators, make up the vehicle's internal network. ECUs are essentially processing systems that monitor, control and manage different aspects of the vehicle's functionality. They receive data from various sensors positioned throughout the vehicle and use this information to make real-time decisions, ensuring that all electronic components and systems of the vehicle work in harmony.
[0008] ECUs manage many different components of a vehicle, such as the engine, windows and the infotainment system. For example, the Engine Control Unit regulates fuel injection, ignition timing and other critical parameters to optimize engine performance, fuel efficiency and emissions. The Transmission Control Module (TCM) ensures smooth gear shifts and efficient power transmission. The Brake Control Unit (BCU) manages the braking system, modulating brake pressure to prevent wheel lock-up and maintain vehicle stability during braking. ECUs also control safety features and driver assistance systems, such as the Anti-lock Braking System (ABS), adaptive cruise control, lane keeping assist and collision warning / avoidance system. These systems use real-time data to enhance driver safety and comfort.
[0009] Figure 1 shows a typical electronic system 10 of a vehicle. In the considered example, the system 10 comprises a plurality of ECUs, for example ECUs 100 to 110, which are connected by one or more communication systems. For example, ECUs 100-106 are connected by a first communication system 200, such as a Controller Area Network (CAN)bus or an Ethernet network. Instead, ECUs 108 and 110 are connected by a second communication system 202 to ECU 100. The second communication system 202 can be, for example, a CAN bus or a Local Interconnect Network (LIN) bus.
[0010] In recent years, interest in security has increased significantly. For example, this implies that safety-relevant communications must be exchanged via the vehicle's communication systems, such as communication systems 200 and 202, ensuring both safety, i.e., the operation of all vehicle components in a condition that avoids any damage or danger, and security, i.e., protection against any cyber-attacks.
[0011] For this reason, solutions for authenticating messages exchanged through the vehicle's communication systems have been proposed. For example, there are many solutions for communications exchanged over an Ethernet network, particularly a network related to TCP / IP or UDP / IP, such as the use of the Transport Layer Security (TLS) protocol. Instead, the solutions proposed for the CAN protocol are typically simpler, because CAN frames have a reduced size. For example, possible solutions are described in the article by Nowdehi, N., Lautenbach, A., Olovsson, T., "In-vehicle CAN message authentication: An evaluation based on industrial criteria," IEEE Vehicular Technology Conference, September 2017, http: / / dx.doi.Org / 10.1109 / VTCFall.2O17.8288327.
[0012] Figure 2 shows a typical communication between a first ECU 40 and a second ECU 42 via a CAN bus 44. In general, the CAN bus can conform to any CAN protocol, such as CAN 2.0, CAN FD or CAN XL.
[0013] The various versions of the CAN protocol specify certain data frames, which comprise a header and a payload. To transmit control data, the CAN protocol is typically used in a master-slave type scenario, where a first ECU 40 sends a command CMD to a second ECU 42. Typically, the second ECU 42 provides a response RSP to the first ECU 40. For example, the command CMD can correspond to a control command or a data read request. Therefore, the response RSP can comprise only a confirmation that the command has been executed (or not executed) and / or any response data.
[0014] However, sending the command CMD and the responses RSP over the CAN bus 44 implies that any other device connected to the CAN bus 44 can monitor the exchanged communications and possibly send othercommands CMD. For example, Figure 1 shows a communication interface 300 configured to exchange data between the CAN bus 200 and a device external to the vehicle, such as a diagnostic interface. For this reason, mechanisms have been provided to guarantee the authenticity of sent messages, including a Message Authentication Code (MAC).
[0015] For example, as shown in Figure 2, a secret key CK shared between ECUs 40 and 42 is typically used. Typically the key CK is not used to encrypt the command CMD or response RSP data, but to compute a signature for the related message, wherein the signature corresponds to the authentication code. For example, as described in the documents NIST-CMAC NIST, Special Publication 800-38B, “Recommendation for Block Cipher Modes of Operation: The CM AC Mode for Authentication", May 2005; or RFC4493 Song J., Poovendran R., Lee J., Iwata T., “The AES-CMAC Algorithm", June 2006, an authentication code, also identified as Cipher Message Authentication Code (CMAC), can be determined using the Advanced Encryption Standard (AES) algorithm. Such documents are incorporated herein by reference. As an alternative to AES or other block ciphering algorithms, ECUs can use hash functions, such as the Message-Digest Algorithm MD5. Indeed, a hash function produces a sequence of bits (or a string), called a digest, strongly correlated to the input data.
[0016] Therefore, ECU 40 includes in the first message the command CMD data and a related authentication code MAC1 , while ECU 42 includes in the second message the response RSP data and a related authentication code MAC2. In particular, the MAC code is computed at least as a function of the related data, i.e. , CMD or RSP, and the secret key CK.
[0017] However, the solution described above has the drawback that a hacker can still intercept the communications, for example via a so-called man-in-the-middle type attack, and resend the same CAN frame of the command CMD even at a later time. ECU 42 would not be able to detect the attack, because the authentication code MAC1 would still be valid. For example, a hacker could intercept a vehicle unlock request or a brake actuator command and subsequently resend the same CAN communication.
[0018] To avoid this problem, solutions exist that compute the authentication code MAC also as a function of a count value, which is incremented for eachcommand CMD. In this way, a message cannot be reused, because the MAC code of the same command CMD would change for a subsequent sending.
[0019] Object and summary
[0020] The inventors have observed that the use of a counter may still be insufficient from a security point of view. In light of the foregoing, various embodiments of the present description concern improved solutions for sending data through a CAN bus.
[0021] In particular, various embodiments of the present description concern a method for communication between two ECUs. Various embodiments also concern a corresponding electronic system and vehicle.
[0022] The scope of protection is defined in the attached claims, which are an integral part of the technical teaching of the present description.
[0023] As mentioned earlier, various forms of the present description concern solutions for authenticated communication between a first electronic control unit (ECU) and a second ECU through a Controller Area Network (CAN) network. This network is commonly used in vehicles for exchanging information between electronic components, but presents vulnerabilities that can be exploited for cyber-attacks. The system can be implemented in a vehicle, where the second ECU is configured to control an electrical or mechanical component, such as an actuator, based on commands received from the first ECU.
[0024] The present description proposes a secure communication system that uses random codes (nonces) and cryptographic signatures to protect the integrity and authenticity of transmitted data.
[0025] In particular, in various embodiments, the communication is based on a two-way authentication mechanism involving both ECUs. The first ECU initiates the process by generating a first random code and transmitting it, together with an initialization message, to the second ECU. The latter responds by generating a second random code and sending it to the first ECU. This exchange of random codes allows each ECU to verify the identity of the other and to synchronize for subsequent secure communications.
[0026] In various embodiments, the first ECU uses the random codes and a command code to compute a signature, for example using the AES-CMAC algorithm. This signature ensures that the command has not been alteredduring transmission. The signature and the command are sent to the second ECU, which verifies the authenticity of the message by computing the same signature and comparing it with the received one. If the verification is successful, the second ECU executes the command and generates a response.
[0027] In various embodiments, the response, together with a second cryptographic signature, is sent to the first ECU to allow the final verification. Only if this verification is also positive is the operation considered successfully completed.
[0028] In various embodiments, robust random codes are used. For this purpose, the random codes are generated by combining a counter component, which can be an incremental value or a timestamp, and a random component, improving security against replay attacks.
[0029] In various embodiments, the ECUs monitor the transmission times between them to detect any anomalies or delays. If the times exceed predefined thresholds, errors are signaled or corrective actions are adopted, such as retransmitting the message or temporarily blocking new messages.
[0030] The solutions are optimized for transmission over CAN networks. For example, each message can be sent with a single CAN frame, or it can be split into two CAN frames to respect bandwidth limitations, with a first frame indicating the start of the message and a second frame indicating its end.
[0031] Therefore, the solutions proposed here provide protection against replay attacks thanks to random codes, cryptographic signatures and the monitoring of transmission times. The proposed solutions are optimized for CAN networks and use frames compatible with existing standards.
[0032] Brief description of the figures
[0033] The invention will now be described with reference to the attached figures, provided by way of non-limiting example only, wherein:
[0034] - Figure 1 shows an example of the electronic system of a vehicle. - Figure 2 shows an example of the communication between two ECUs of the electronic system of Figure 1 ;
[0035] - Figure 3 shows an embodiment of the communication between two ECUs according to the present description;
[0036] - Figures 4A and 4B show a flow diagram of the operation of the ECUs of Figure 3;- Figures 5Ato 5D show operations performed by the ECUs of Figure 3; and
[0037] - Figures 6Ato 6D show messages exchanged between the ECUs of Figure 3.
[0038] Detailed description
[0039] In the following description, numerous specific details are illustrated for the purpose of providing a thorough understanding of the embodiments. The embodiments may be implemented without one or more of the specific details or with other procedures, components, materials, etc. In other instances, well-known operations, materials or structures are not shown or described in detail to avoid obscuring certain aspects of the embodiments.
[0040] A reference to "an embodiment" throughout this description is intended to indicate that a particular configuration, structure, or feature described in connection with the embodiment is included in at least one embodiment. Thus, phrases such as "in one embodiment" or similar that appear at various points throughout this description do not necessarily all refer to the same embodiment. Furthermore, particular configurations, structures or features may be combined in any suitable manner in one or more embodiments.
[0041] The references used here are provided merely for convenience and do not define the scope or meaning of the embodiments.
[0042] In the following Figures 3 to 6, parts, elements or components already described with reference to Figures 1 and 2 are indicated with the same references previously used in those Figures; the description of such previously described elements will not be repeated in the following to avoid burdening the present detailed description.
[0043] As mentioned earlier, various embodiments of the present description concern solutions for improving security in communication systems that use a CAN bus.
[0044] Figure 3 shows an embodiment of the communication between a first ECU 40a and a second ECU 42a, connected via a CAN bus 44 or a more complex CAN network. For example, the CAN network 44 may comprise any gateway nodes that forward communication between multiple communication systems. For a general description of ECUs, reference can be made to Figures 1 and 2. Therefore, also in Figure 3, ECU 40a isconfigured to send a command CMD and ECU 42a is configured to send a response RSP to the command CMD.
[0045] As illustrated earlier, communication over a CAN network is vulnerable to attacks that can compromise both the integrity and authentication of messages, jeopardizing vehicle security. To address this problem, the present description proposes solutions based on the use of authenticated commands, implemented through the integration of nonce and MAC.
[0046] In particular, various embodiments of the present description use a communication protocol that employs unique values, known as nonce, generated and used for each message exchanged between two ECUs. In various embodiments, the mechanism can be used for all commands or only for those that may have safety relevance. For example, the commands may relate to sending a command to unlock or lock an electronic steering, respectively in response to a vehicle ignition or shutdown request, a command to start or stop a vehicle propulsion engine, respectively in response to a vehicle ignition or shutdown request, or commands received from external entities to perform operations within the vehicle, such as, for example, remote management.
[0047] In particular, in various embodiments, the generation of the nonce combines a counter component and a random component.
[0048] The counter component is provided by a hardware or software counter. In various embodiments, the counter is configured to provide a consecutive count value, maintained even during the lifecycle of the respective ECU. For example, for this purpose, the count value is stored in a non-volatile memory when the ECU is powered off and retrieved from the memory when the ECU is powered on. For example, the ECU may increment the count value for each communication session, each command sent and / or received, periodically, etc. In various embodiments, the counter may correspond to a real-time clock (RTC), i.e., the count value may correspond to a timestamp. Therefore, in various embodiments, this counting component guarantees the uniqueness of the nonce during the entire vehicle lifecycle, preventing any accidental repetition. Therefore, in various embodiments the count value provided by the counter has a plurality of bytes, for example 2, 4 or 8 bytes.The random component can be produced using hardware or software generators. This component allows preventing predictions by potential attackers. Therefore, in various embodiments, the ECU is configured to generate a nonce ensuring that each value is unique and unpredictable. In various embodiments, the random component has a plurality of bytes, for example 3 or 5 bytes.
[0049] Therefore, in various embodiments, the nonce may correspond to a concatenation of the counter component and the random component. However, in various embodiments, other solutions may also be used to generate the nonce which has a given number of bytes as a function of the counter component and the random component, for example via a hash function.
[0050] In various embodiments, the protocol is structured in several phases to ensure the security and reliability of the information exchange.
[0051] In particular, during an initialization phase, the source ECU 40a initiates the process by generating a value Nonce2. This nonce is inserted into a "Hello" type message 500, which is sent to the destination ECU 42a. Sending the nonce Nonce2 allows starting the authenticated communication. For example, a CAN-HS (CAN High-Speed) frame typically has 8 bytes. Therefore, such a frame may comprise one byte indicating the message type and 7 bytes for additional data. For example, in this case, the nonce may comprise 2 (or 4) bytes of the counter component and 5 (or 3) bytes of the random component. In contrast, a CAN-FD (CAN Flexible Data-Rate) frame may comprise up to 64 bytes. Therefore, in this case, the nonce may have a chosen number of bytes, for example between 7 and 63 bytes, preferably between 31 and 63 bytes. In various embodiments, the nonce may also have a number of bytes that is greater than the size of the CAN frame, and the message may be transmitted via a plurality of CAN frames.
[0052] The destination ECU 42a, after receiving the Hello message 500, in turn generates a new value Noncel and includes it in a response message 502 directed to the source ECU 40a. This initial exchange creates a common and secure context for subsequent operations.
[0053] In various embodiments, during an authenticated command sending phase, the source ECU 40a prepares a command message 504 to send. For this purpose, the source ECU 40a generates a string STR1 composedof the command CMD to be sent, the value Nonce2 generated by ECU 40a and the value Noncel received from ECU 42a. For example, in various embodiments, the string STR1 comprises in sequence the command CMD, the value Nonce2 and the value Noncel (i.e. , CMD || Nonce2 || Noncel ). In various embodiments, the string STR1 may also include one or more data from the CAN frame header, such as the identification of ECU 40a and the identification of ECU 42a.
[0054] Subsequently, the source ECU 40a computes a signature, i.e., a message authentication code, MAC1 as a function of the string STR1 and a secret key CK. Therefore, in various embodiments, both ECUs 40a and 42a store the secret key CK. The secret key CK can be constant and stored in the ECUs during production, or known mechanisms can be provided to send the secret key CKto the ECUs. The secret key CK can be common to all ECUs of the vehicle or to a subset of ECUs. For example, in various embodiments, the secret key CK can be unique for each pair of ECUs. With reference to Figure 1 , for example, ECUs 100, 108 and 110 can use a single secret key CK for communication among themselves, while a respective secret key CK can be used for communication between two ECUs chosen from among ECUs 100-106. For example, communication between ECUs 100 and 102 can use a first secret key CK, while communication between ECUs 100 and 104 can use a second secret key CK.
[0055] In various embodiments, the source ECU 40a computes the message authentication code MAC1 via a hash function, concatenating the string STR1 with the secret key CK. Alternatively, the source ECU 40a can compute the message authentication code MAC1 by generating a signature for the string STR1 using the secret key as an encryption key. For example, in various embodiments, the source ECU 40a uses AES to compute a Cipher Message Authentication Code (CMAC) conforming to international standards (NIST SP 800-38B and RFC 4493).
[0056] In other embodiments, instead of using symmetric cryptography with a shared key CK, signatures with asymmetric cryptography can be used, wherein each ECU stores a first key (typically a private key) to generate the signature, i.e., the message authentication code, and a second key (typically a public key) to verify the message received from the other ECU. In this way, a mechanism for exchanging a secret key CK is not necessary;it is sufficient for each ECU to send its public key to the other ECU. For example, in various embodiments, the public key can be sent via a certificate, similar to an X.509 certificate, which also includes a signature from a trusted entity, such as a signature from the vehicle manufacturer.
[0057] Therefore, the source ECU 40a generates the command message 504, i.e., one or more related CAN frames, which comprise in the header the identification of ECU 40a (as sender) and the identification of ECU 42a (as destination), and in the payload the command CMD and the message authentication code MAC1. The source ECU 40a sends the CAN frame(s) via the CAN network 44 to the destination ECU 42a.
[0058] In various embodiments, during a verification and response phase, the destination ECU 42a verifies the authenticity and integrity of the command CMD by computing a new message authentication code MAC based on the nonce and comparing it with the received MAC1 value. Following a positive verification, the destination ECU 42a executes the command CMD and generates a respective response RSP.
[0059] Subsequently, the destination ECU 42a prepares the response message 506 to send. For this purpose, the destination ECU 42a generates a string STR2 composed of the response RSP, the value Noncel generated by ECU 42a and the value Nonce2 received from ECU 40a. For example, in various embodiments, the string STR2 comprises in sequence the response RSP, the value Noncel and the value Nonce2 (i.e., RSP || Noncel || Nonce2). In various embodiments, the string STR2 may also include one or more data from the CAN frame header, such as the identification of ECU 42a and the identification of ECU 40a.
[0060] Subsequently, the destination ECU 42a computes a message authentication code MAC2 as a function of the string STR2 and the secret key CK, preferably using the same algorithm employed by the source ECU 40a to generate the MAC1 code. The destination ECU 42a then generates a response message 506, i.e., one or more related CAN frames, which comprise in the header the identification of ECU 42a (as sender) and the identification of ECU 40a (as destination) and in the payload the response RSP and the message authentication code MAC2. ECU 42a sends the CAN frame(s) via the CAN network 44 to ECU 40a.
[0061] Finally, in various embodiments, during a verification phase, thesource ECU 40a verifies the authenticity and integrity of the response RSP by computing a new message authentication code MAC based on the nonce and comparing it with the received MAC2 value.
[0062] In various embodiments, to adapt to the limitations of the CAN bus, such as the maximum message length, the MACs can be truncated using the least significant bits, while still preserving a high level of security. For example, similar to the nonce, the MAC code can have 7 bytes for CAN-HS or up to 63 bytes for CAN-FD.
[0063] In various embodiments, the ECUs are configured to verify the times between the various messages. For example, ECU 40a can monitor the time between messages 500 and 502 and compare it with a threshold T1 which corresponds to the maximum allowed time to complete the initial nonce exchange. Similarly, ECU 42a can monitor the time between messages 502 and 504 and compare it with a threshold T2 which establishes the time limit for receiving the command CMD. Finally, ECU 40a can monitor the time between messages 504 and 506 and compare it with a threshold T3 which determines the time window for sending the response RSP.
[0064] In case of errors, such as the expiration of a timer or a mismatch of a MAC, the ECUs can adopt various countermeasures. For example, when ECU 40a does not receive message 502 or 506, it can start a new communication. Additionally or alternatively, for example when a MAC code verification has given a negative result, the respective ECU can introduce delays before accepting new messages. This approach reduces the risk of brute force attacks and ensures that only fresh messages are accepted.
[0065] Thanks to the use of nonce and timers, the proposed solution is able to effectively prevent the execution of duplicate or repeated commands. Each message is unique and the freshness mechanism ensures that commands are executed only if sent within a specific time interval. This reduces the risk of attacks based on recorded and retransmitted messages. Furthermore, the system is able to handle error scenarios robustly. When a problem occurs, such as a timeout or a failed MAC verification, mitigation measures are applied to prevent repeated attacks, while ensuring operational continuity.
[0066] This approach represents a significant step forward in the security ofCAN networks for connected vehicles. The combination of unique nonce and authentication via MAC offers an effective solution to mitigate network vulnerabilities, such as replay attacks and message manipulation. Furthermore, the protocol architecture is sufficiently flexible to be adapted to different application contexts.
[0067] Figures 4A and 4B show a possible embodiment of the operation of ECUs 40a and 42a. In particular, the left portion shows the steps executed by ECU 40a, while the right portion shows the steps executed by ECU 42a.
[0068] After a start step 1000, ECU 40a generates, at a step 1002, the value Nonce2. As explained previously, in various embodiments ECU 40a generates the value Nonce2 as a function of a count value (preferably permanent) and a random value.
[0069] Subsequently, the ECU generates, at a step 1004, the Hello message 500. For example, Figure 6A shows an example of the message 500, which is then included as payload within one or more related CAN frames. As explained previously, each CAN frame comprises additional data of the CAN protocol, such as the CAN header. For example, in the considered embodiment, a first field specifies a command code CMDH associated with the Hello message and a second field comprises the value Nonce2. For example, the command field can comprise one or more bytes. In the considered embodiment, the command field consists of one byte and the field for the value Nonce2 consists of N bytes, for example 7 bytes for CAN-HS or up to 63 bytes for CAN-FD. Therefore, in the considered embodiment, ECU 40a inserts, at step 1004, a CMDH value identifying the Hello message in the command field and the value Nonce2 in the related field.
[0070] However, in various embodiments, the Hello message can also have a size that is greater than the number of bytes of the CAN frame payload. For instance, in the case of CAN-HS, the Hello message can have a size of 14 bytes. However, in the case of CAN-HS, the CAN message has only a payload of 8 bytes. For this reason, the message 500 can be transmitted via two consecutive CAN frames. For example, in this case, one byte, for instance the first byte, can comprise metadata to manage the transmission of a sequence of CAN frames, such as indications that the frame is the first of a sequence, an intermediate frame or the last frame of a sequence. However, other metadata can also be used to indicate the start and end ofa frame sequence. Therefore, in various embodiments, the first CAN frame can comprise the Hello command CMDH and 6 bytes of the value Nonce2, while the second CAN frame can comprise further 7 bytes of the value Nonce2. Therefore, in this case, the nonce has 13 bytes, for example 8 bytes for the count value and 5 bytes of the random component.
[0071] Furthermore, ECU 40a sets, at a step 1006, the timeout condition of a timer 2000 to the value T1 and sends, at a step 1008, the Hello message 500 via the CAN network 44 to ECU 42a.
[0072] Therefore, ECU 42a receives, at a step 1010, a message from ECU 40a. In response to receiving the message, ECU 42a analyzes the content of the message, in particular to determine if the command field comprises the value CMDH. In response to a determination that the message is a Hello message 500, i.e. , that the command field comprises the CMDH value of a Hello message, ECU 42a stores the transmitted value Nonce2. Furthermore, ECU 42a executes a sequence of operations.
[0073] In particular, in the considered embodiment, ECU 42a generates, at step 1012, the value Noncel as a function of a count value and a random value.
[0074] Subsequently, the ECU generates at a step 1014 the response message 502. For example, Figure 6B shows an example of the message 502, which is then included as payload within one or more related CAN frames. In the considered embodiment, a first field specifies the response RSPH and a second field comprises the value Noncel. For example, the response field can comprise one or more bytes. In the considered embodiment, the response field consists of one byte, while the field for Noncel consists of N bytes, for example 7 bytes for CAN-HS, 13 bytes for CAN-HS with multi-frame or up to 63 bytes for CAN-FD. Therefore, in the considered embodiment, ECU 42a inserts at step 1014 an RSPH value identifying a positive response to a Hello message in the response field and the value Noncel in the related field. In various embodiments, in case ECU 42a did not detect a Hello message 500, it could insert in the response field a value identifying an error and omit the generation of the value Noncel .
[0075] For example, in the case of CAN-HS with multi-frame, the response message 502 can have a length of 14 bytes. For this reason, the message 502 can be transmitted via two consecutive CAN frames, each with apayload of 8 bytes. For example, in various embodiments, the first CAN frame can comprise the response RSPH and 6 bytes of the value Noncel , while the second CAN frame can comprise the remaining 7 bytes of the value Noncel .
[0076] Furthermore, ECU 42a sets at a step 1016 the timeout condition of a timer 2002 to the value T2 and sends at a step 1018 the response message 502 via the CAN network 44 to ECU 40a.
[0077] Therefore, ECU 40a receives at a step 1020 a message from ECU 42a. In response to receiving the message, ECU 40a analyzes the content, in particular to determine if the response field comprises the value RSPH indicating a positive response to a Hello message. In case of a positive determination, i.e. , that the received message is a response 502 to a Hello message 500, ECU 40a stores the transmitted value Noncel .
[0078] As schematically shown in Figure 4A, timer 2000 is started in response to sending the Hello message 500 and stopped in response to receiving the response message 502. Furthermore, timer 2000 is configured to signal a timeout condition when it exceeds a threshold set at step 1006 to the value T1. Therefore, when timer 2000 reaches the threshold T1, it signals the timeout condition, for example via an interrupt. In response to this signaling, ECU 40a proceeds to an error step 1100 and the method ends at the finish step 1102. For example, ECU 40a can generate an error signal at step 1100.
[0079] Conversely, when the timeout condition is not reached, ECU 40a executes a sequence of operations. In particular, in various embodiments, ECU 40a calculates at a step 1022 the authentication code MAC1 as a function of a command CMD to be sent. For example, as shown in Figure 5A, ECU 40a performs an operation via a software module and / or encryption circuit 400, which receives as input, for example sequentially, the command CMD, the value Nonce2 and the value Noncel , and generates a signature MAC1 also using a key CK. As explained previously, the key CK can be a shared key or a private key of ECU 40a. For example, ECU 40a calculates the MAC1 code as a CMAC code using AES.
[0080] Subsequently, the ECU generates at step 1024 the command message 504. For example, Figure 6C shows an example of the message 504, which is then included as payload within one or more related CANframes. In the considered embodiment, a first field specifies a command code CMD and a second field comprises the value MAC1. For example, the command field can comprise one or more bytes. In the considered embodiment, the command field consists of one byte, while the field for the value MAC1 consists of N bytes, for example 7 bytes for CAN-HS, 13 bytes for CAN-HS with multi-frame or up to 63 bytes for CAN-FD. Therefore, in the considered embodiment, ECU 40a inserts at step 1024 the CMD value identifying the command to be executed in the command field and the value MAC1 in the related field. In this context, in typical signature algorithms, the signature is at least 16 bytes. In that case, the value MAC1 can correspond to the least significant bits / bytes of the computed signature.
[0081] For example, in the case of CAN-HS with multi-frame, the command message 504 can have a length of 14 bytes. For this reason, the message 504 can be transmitted via two consecutive CAN frames, each with a payload of 8 bytes. For example, in various embodiments, the first CAN frame can comprise the command CMD and 6 bytes of the value MAC1, while the second CAN frame can comprise the remaining 7 bytes of the value MAC1.
[0082] Furthermore, ECU 40a sets at step 1026 the timeout condition of a timer 2004 to the value T3 and sends at step 1028 the command message 504 via the CAN network 44 to ECU 42a. In various embodiments, timer 2004 corresponds to timer 2000.
[0083] Therefore, ECU 42a receives at step 1030 a message from ECU 40a. In response to receiving the message, ECU 42a analyzes the content of the message, in particular to determine if the command field comprises the value CMD of an accepted command. In case of a determination that the message is a (accepted) command message 504, ECU 42a stores the transmitted value MAC1.
[0084] As schematically shown in Figure 4A, timer 2002 is started in response to sending the response message 502 (with the value RSPH) and is stopped in response to receiving the command message 504. Furthermore, timer 2002 is configured to signal a timeout condition when it exceeds a threshold set at step 1016 to the value T2. Therefore, when timer 2002 reaches the threshold T2, it signals the timeout condition, for example via an interrupt. In response to the signaling of the timeout condition, ECU42a proceeds to error step 1200 and the method ends at finish step 1202. For example, ECU 42a can generate an error signal at step 1200.
[0085] On the contrary, when the timeout condition is not reached, ECU 42a executes a sequence of operations. In particular, in various embodiments, ECU 42a verifies at a step 1032 the authentication code MAC1. For example, as shown in Figure 5B, ECU 42a performs an operation, for example via a respective software module and / or encryption circuit 420, which receives as input, for example in sequence, the command CMD, the value Nonce2 and the value Noncel , and generates a signature also using for this purpose a key CK. As explained previously, the key CK can be a shared key or a public key of ECU 40a. For example, ECU 42a calculates a CMAC code using AES.
[0086] Therefore, in the considered embodiment, ECU 42a compares at a step 1034 the calculated signature with the received signature MAC1. For example, in Figure 5B, the software module and / or encryption circuit 420 asserts a signal T / F when the calculated signature corresponds to the received signature MAC1. As mentioned, the MAC1 value may correspond to the least significant bits / bytes of the calculated signature. Therefore, the received MAC1 code can be compared with the calculated least significant bits / bytes.
[0087] In case of a determination that the calculated signature does not correspond to the received signature MAC1 (output "N" of verification step 1034), for example when the signal T / F is de-asserted, ECU 42a proceeds to error step 1200.
[0088] On the contrary, in case of a determination that the calculated signature corresponds to the received signature MAC1 (output "Y" of verification step 1034), for example when the signal T / F is asserted, ECU 42a proceeds to a step 1036, wherein it executes the operation indicated by the command code CMD, obtains at a step 1038 the result of the executed operation and associates a respective response code RSP.
[0089] Subsequently, in various embodiments, ECU 42a calculates at a step 1040 the authentication code MAC2 as a function of a response code RSP to be sent. For example, as shown in Figure 5C, ECU 42a performs an operation, for example via a respective software module and / or encryption circuit 422, which receives as input, for example in sequence, the responseRSP, the value Noncel and the value Nonce2, and generates a signature MAC2 also using for this purpose a key CK. As explained previously, the key CK can be a shared key or a private key of ECU 42a. For example, ECU 42a calculates the MAC2 code as a CMAC code using AES.
[0090] Subsequently, ECU 42a generates at step 1042 the response message 506. For example, Figure 6D shows an example of the message 506, which is then included as payload within one or more related CAN frames. In the considered embodiment, a first field specifies a response code RSP and a second field comprises the value MAC2. For example, the response field can comprise one or more bytes. In the considered embodiment, the response field consists of one byte, while the field for the value MAC2 consists of N bytes, for example 7 bytes for CAN-HS, 13 bytes for CAN-HS with multi-frame or up to 63 bytes for CAN-FD. Therefore, in the considered embodiment, ECU 42a inserts at step 1042 the RSP value identifying the result of the executed operation in the response field and the value MAC2 in the related field. As mentioned, the MAC2 value may correspond to the least significant bits / bytes of the calculated signature.
[0091] For example, in the case of CAN-HS with multi-frame, the response message 506 can have 14 bytes. For this reason, the message 506 can be transmitted via two consecutive CAN frames, wherein each CAN frame has a payload of 8 bytes. For example, in various embodiments, the first CAN frame can comprise the response RSP and 6 bytes of the value MAC2, while the second CAN frame can comprise the remaining 7 bytes of the value MAC2.
[0092] Furthermore, ECU 42a sends at a step 1044 the response message 506 via the CAN network 44 to ECU 40a.
[0093] Therefore, ECU 40a receives at a step 1046 a message from ECU 42a. In response to receiving the message, ECU 40a analyzes the content of the message, in particular to determine if the response field comprises the RSP value of a valid response. In case of a determination that the message is a (accepted) response message 506, ECU 40a stores the transmitted MAC2 value.
[0094] As schematically shown in Figure 4B, timer 2004 is started in response to sending the command message 504 (with the CMD value) and stopped in response to receiving the response message 506. Furthermore,timer 2004 is configured to signal a timeout condition when it exceeds a threshold set at step 1026 to the value T3. Therefore, when timer 2004 reaches the threshold T3, it signals the timeout condition, for example via an interrupt. In response to the signaling of the timeout condition, ECU 40a proceeds to error step 1100 and the method terminates at end step 1102.
[0095] On the contrary, when the timeout condition is not reached, ECU 40a executes a sequence of operations. In particular, in various embodiments, ECU 40a verifies at a step 1048 the authentication code MAC2. For example, as shown in Figure 5D, ECU 40a performs an operation, for example via a respective software module and / or encryption circuit 422, which receives as input, for example in sequence, the response RSP, the value Noncel and the value Nonce2, and generates a signature also using for this purpose a key CK. As explained previously, the key CK can be a shared key or a public key of ECU 42a. For example, ECU 40a calculates a CMAC code using AES.
[0096] Therefore, in the considered embodiment, ECU 40a compares at a step 1050 the calculated signature with the received signature MAC2. For example, in Figure 5D, the software module and / or encryption circuit 422 asserts a signal T / F when the calculated signature corresponds to the received signature MAC2. As mentioned, the MAC2 value may correspond to the least significant bits / bytes of the calculated signature. Therefore, the received MAC2 code can be compared with the calculated least significant bits / bytes.
[0097] In case of a determination that the calculated signature does not correspond to the received signature MAC2 (output "N" of verification step 1050), for example when the signal T / F is de-asserted, ECU 40a proceeds to error step 1100.
[0098] Instead, in case of a determination that the calculated signature corresponds to the received signature MAC2 (output "Y" of verification step 1050), for example when the signal T / F is asserted, ECU 40a proceeds to a step 1052, wherein it executes any further operations as a function of the response RSP and the method terminates at an end step 1054.
[0099] Therefore, the solutions described here are capable of guaranteeing security in communications over CAN networks through the use of unique nonce (Noncel and Nonce2) and message authentication codes (MAC1and MAC2). In particular, the present description concerns a secure protocol for exchanging CMD commands between electronic control units, designed to prevent replay attacks, ensure message integrity and authenticate the origin of communications.
[0100] For this purpose, in various embodiments, each exchange of a CMD command comprises the generation of unique values (nonces) that combine a random component and a counter component. This guarantees both the uniqueness and unpredictability of the generated values. The initial exchange of nonce between the ECUs allows establishing a secure context for the subsequent transmission of the CMD command.
[0101] In various embodiments, the MACs are calculated by concatenating the relevant data (e.g., commands and nonce) and using a secret key CK, guaranteeing the integrity and authenticity of the message. For example, the ECUs can use an authentication algorithm based on CMAC codes, conforming to standards NIST SP 800-38B and RFC 4493.
[0102] The implementation of specific timers (T 1 , T2, T3) ensures that each command is executed only within a predefined time window, preventing the use of stale or duplicate messages.
[0103] In case of failed authentication or timer expiration, the system can adopt mitigation measures, such as delays in accepting new commands, to prevent brute force attacks.
[0104] The thresholds T1, T2 and T3 can be customized based on the specific characteristics of the system. For example, CAN networks with higher traffic might require higher thresholds. Instead, safety-critical vehicle applications might use lower thresholds.
[0105] The protocol is designed to be compatible with the limitations of the CAN bus, such as the reduced message length, possibly using truncation techniques for the MACs without compromising security.
[0106] Naturally, without prejudice to the principle of the invention, the details of construction and the embodiments may vary widely with respect to what has been described and illustrated without thereby departing from the scope of the present invention, as defined in the attached claims.
Claims
CLAIMS1. A method for communication between a first electronic control unit, ECU, (40a) and a second ECU (42a) through a Controller Area Network, CAN, (44) to perform an operation by said second ECU (42a), the method comprising:- performing the following operations by said first ECU (40a):- generating (1002) a first random code (Nonce2), - generating (1004) a first message (500) comprising said first random code (Nonce2),- transmitting (1008) said first message (500) through one or more CAN frames to said second ECU (42a);- performing the following operations by said second ECU (42a) in response to receiving (1010) said first message (500):- extracting said first random code (Nonce2) from said first message (500),- generating (1012) a second random code (Noncel), - generating (1014) a second message (502) comprising said second random code (Noncel),- transmitting (1018) said second message (502) through one or more CAN frames to said first ECU (40a);- performing the following operations by said first ECU (40a) in response to receiving (1020) said second message (502):- extracting said second random code (Noncel) from said second message (502),- calculating (1022) a first signature (MAC1 ) as a function of a command code (CMD) associated with said operation, said first random code (Nonce2), and said second random code (Noncel), - generating (1024) a third message (504) comprising said command code (CMD) and said first signature (MAC1),- transmitting (1028) said third message (504) through one or more CAN frames to said second ECU (42a);- performing the following operations by said second ECU (42a) in response to receiving (1030) said third message (504):- extracting said command code (CMD) and said firstsignature (MAC1) from said third message (504),- calculating (1032) a signature as a function of the extracted command code (CMD), said first random code (Nonce2), and said second random code (Noncel),- determining (1034) whether said calculated signature corresponds to said extracted first signature (MAC1),- in response to determining that said calculated signature corresponds to said extracted first signature (MAC1):- performing (1036) the operation associated with said extracted command code (CMD),- obtaining (1038) a response code (RSP) associated with the result of said performed operation,- calculating (1040) a second signature (MAC2) as a function of said response code (RSP), said second random code (Noncel), and said first random code (Nonce2),- generating (1042) a fourth message (506) comprising said response code (RSP) and said second signature (MAC2), - transmitting (1044) said fourth message (506) through one or more CAN frames to said first ECU (40a);- performing the following operations by said first ECU (40a) in response to receiving (1046) said fourth message (506):- extracting said response code (RSP) and said second signature (MAC2) from said fourth message (506),- calculating (1048) a signature as a function of the response code (RSP) extracted, said second random code (Noncel), and said first random code (Nonce2),- determining (1050) whether said calculated signature corresponds to said extracted second signature (MAC2),- in response to determining that said calculated signature corresponds to said extracted second signature (MAC2):- classifying (1052) the result of said operation as a function of said extracted response code (RSP).
2. The method according to Claim 1 , wherein said first random code (Nonce2) and said second random code (Noncel) are generated by combining a counter component and a random component.
3. The method according to Claim 2, wherein said counter component corresponds to a count value that is incremented for each first message (500) or periodically, or corresponds to a timestamp.
4. The method according to any of the previous claims, wherein said first signature (MAC1) and said second signature (MAC2) are calculated using the AES-CMAC algorithm compliant with the NIST SP 800-38B and RFC 4493 standards, with a secret key (CK) shared between the ECUs.
5. The method according to any of the previous claims, wherein: - said first ECU (40a) monitors the time between the transmission of said first message (500) and the reception of said second message (502), and in response to determining that the time between the transmission of said first message (500) and the reception of said second message (502) exceeds a first threshold (T1), signals an error (1100);- said second ECU (42a) monitors the time between the transmission of said second message (502) and the reception of said third message (504), and in response to determining that the time between the transmission of said second message (502) and the reception of said third message (504) exceeds a second threshold (T2), signals an error (1200); and- said first ECU (40a) monitors the time between the transmission of said third message (504) and the reception of said fourth message (506), and in response to determining that the time between the transmission of said third message (504) and the reception of said fourth message (506) exceeds a third threshold (T3), signals an error (1100).
6. The method according to Claim 5, wherein:- in response to determining that the time between the transmission of said first message (500) and the reception of said second message (502) exceeds a first threshold (T1), said first ECU (40a) retransmits said first message (500); and- in response to determining that the time between the transmission of said second message (502) and the reception of said third message (504) exceeds a second threshold (T2), said second ECU (42a) does not accept new messages for a predetermined time.
7. The method according to any of the previous claims, wherein each of said first (500), second (502), third (504), and fourth (506) messages has8 bytes for CAN High-Speed or between 8 and 64 bytes for CAN Flexible Data-Rate.
8. The method according to any of the previous claims from 1 to 6, wherein each of said first (500), second (502), third (504), and fourth (506) messages has 14 bytes, wherein each of said first (500), second (502), third (504), and fourth (506) messages is transmitted through a sequence of a respective first CAN High-Speed frame and a respective second CAN High-Speed frame.
9. The method according to Claim 8, wherein:- the first CAN frame comprises data indicating the beginning of the transmission of a message, and- the second CAN frame comprises data indicating the end of the transmission of a message.
10. The method according to any of the previous claims from 7 to 9, wherein:- said first message (500) comprises a command code (CMDH) identifying a "Hello" type message, wherein said command code (CMDH) has one byte and said first random code (Nonce2) corresponds to the remaining bytes of the message;- said second message (502) comprises a response code to a "Hello" type message (RSPH), wherein said response code to a "Hello" type message (RSPH) has one byte and said second random code (Noncel) corresponds to the remaining bytes of the message;- said command code (CMD) has one byte and said first signature (MAC1) corresponds to the remaining bytes of the message; and- said response code (RSP) has one byte and said second signature (MAC2) corresponds to the remaining bytes of the message.
11. An electronic system comprising a first electronic control unit, ECU, (40a) and a second ECU (42a) connected via a Controller Area Network (44), wherein said first ECU (40a) and said second ECU (42a) are configured to implement the method according to any of the previous claims.
12. A vehicle comprising the electronic system of Claim 11, wherein said second ECU (42a) is configured to control an electrical or mechanical component of said vehicle based on said command code (CMD).