Method and system for exchanging data on network that enhances security means for network and vehicle including such type of system

Abstract

To provide a method and a system for data exchange that enhance security means for data transmitted on a network.SOLUTION: In a method for data exchange on a communication network 2 including a transmission bus 4, a first node E1, and a second node En, the first node constructs first and second data frames that transmit first and second information data. The first node then constructs a third data frame that transmits a first message authentication code calculated as a function of the first and second information data. The second node receives the first, second, and third data frames and extracts the first and second information data and the first message authentication code. The second node then calculates a second message authentication code as a function of the extracted first and second information data and compares the extracted message authentication code with the calculated message authentication code.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This patent application claims priority to Italian Patent Application No. 102019000023544, filed December 10, 2019, the entire disclosure of which is incorporated herein by reference.

[0002] The present invention relates to a method and system for data exchange over a communications network, in particular for enhancing security measures for data transmitted over the network, and to a vehicle incorporating such a system. [Background technology]

[0003] Modern electronic systems for automobiles provide for the use of software running on Electronic Control Units (ECUs) that communicate with each other in a network via serial buses and gateways. Most of the current systems are not designed with consideration of the security of the on-board data against internal or external attacks, for example, created with the intention of modifying the data exchanged and causing malfunctions, modifications or crashes of the motor control applications and / or vehicle applications.

[0004] The processes, methods, and instrumentation used for the design of modern automotive electronic systems are focused on optimizing reliability and cost. Methods and instrumentation for testing the reliability of automotive electronic systems for random failures are commercially available.

[0005] However, security-related aspects are rarely taken into account during the development of hardware and software architectures; at the same time, standard communication protocols also do not provide shared methods to prevent or mitigate attacks.

[0006] On-board vehicle communication networks are vulnerable because, ultimately, all communication between ECUs within the vehicle is performed without sufficient authentication mechanisms to ensure that the identities of the sender and receiver have not been compromised, allowing unauthorized access in a relatively simple manner.

[0007] Unfortunately, current communication network protocols such as CAN (Controller Area Network), FlexRay, MOST, and LIN, to name a few, do not require authentication or at best only have error control mechanisms (CRC) to ensure data integrity and transmit messages in the clear.

[0008] Therefore, the possibility of unauthorized communication exists between the control units.

[0009] With particular regard to the CAN protocol, in order to overcome the drawbacks mentioned above, various solutions have been proposed aiming at improving security, especially in the sense of message authenticity and information freshness.

[0010] For example, Non-Patent Document 1 proposes a reconsideration of the structure or format of CAN messages in order to include fields related to control codes. However, such a solution would entail a general adaptation of the implemented protocols, which must allow the interpretation of the new message structures.

[0011] Other technical solutions provide for the introduction of new messages with control functions adapted to carry control information calculated on the application data contained in the concrete message to be protected, see Non-Patent Document 2, and also Non-Patent Document 3. However, these solutions are not optimal since they significantly increase the traffic and the computational load on the network.

[0012] A further solution offers the use of the more recently introduced CAN protocol, called CAN-FD, which involves increased data rates (>1 Mbit / s) and increased payload (>8 Byte), optimizing data transmission and thus increasing the possibilities for the implementation of solutions aimed at improving security. However, this solution has the drawback of requiring a re-adaptation of the on-board vehicle data exchange system, making a conversion to the new protocol mandatory, with the resulting costs therefore. [Prior art documents] [Non-patent literature]

[0013] [Non-Patent Document 1] Hiroshi Ueda et al., "Security Authentication System for In-Vehicle Network," SEI TECHNICAL REVIEW, No. 81, October 2015 [Non-Patent Document 2] Chung-Wei Lin et al., "Cyber-Security for the Controller Area Network (CAN) Communication Protocol," ASE Conference on Automated Software Engineering, 2012 [Non-Patent Document 3] Pal-Stefan Murvay et al., "Security Shortcomings and Countermeasures for the SAE J1939 Commercial Vehicle Bus Protocol," IEEE Transactions on Vehicular Technology, Volume 67, Issue 5, May 2018. Summary of the Invention [Problem to be solved by the invention]

[0014] The object of the present invention is to provide a solution to the above mentioned drawbacks, which makes it possible to increase the security of information transferred between ECUs belonging to the same vehicle network in an efficient and cost-effective manner and without the need for an increased computational load and / or modification of hardware resources. [Means for solving the problem]

[0015] Thus, according to the present invention there is provided a method and system for exchanging data over a communications network, and a vehicle incorporating such a system, as defined in the accompanying claims.

[0016] For a better understanding of the invention, preferred embodiments will now be described, by way of non-limiting example, with reference to the accompanying drawings in which: [Brief description of the drawings]

[0017] [Figure 1] 1 is a schematic diagram illustrating a network between nodes belonging to a data transmission / reception network implemented in a vehicle. [Diagram 2]2 illustrates a diagram of data frames exchanged between nodes of the network of FIG. 1. [Diagram 3] 2 is a flow chart illustrating a case of transmission of a method implemented by a node of the network of FIG. 1; [Figure 4] 2 is a diagram illustrating an authentication frame exchanged between nodes of the network of FIG. 1. [Diagram 5] 2 is a flow chart illustrating a receiving case of a method implemented by a node of the network of FIG. 1; [Figure 6A] FIG. 2 is a functional block diagram illustrating the operations performed by the nodes of the network of FIG. 1 during a transmission step. [Figure 6B] FIG. 2 is a functional block diagram illustrating the operations performed by the nodes of the network of FIG. 1 during a receiving step. [Figure 7A] FIG. 2 is a functional block diagram illustrating the operations performed by the nodes of the network of FIG. 1 during a synchronization step of the local monotonic counters. [Figure 7B] FIG. 2 is a functional block diagram illustrating the operations performed by the nodes of the network of FIG. 1 during a synchronization step of the local monotonic counters. [Figure 8] FIG. 2 is a schematic diagram illustrating a vehicle including the network of FIG. 1. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0018] FIG. 1 shows a schematic diagram of a communication network 2 operating according to a send / receive protocol. The network 2 comprises a number of nodes E 1 , E 2 , ,E N A bus 4 to which E N represents the Nth node; where N is selected according to the needs of a particular application.

[0019] In one embodiment of the invention, the transmission protocol is of the CAN ("Controller Area Network") type. In this case, the bus 4 is a CAN bus. In the context of the invention, explicit reference is made to a CAN protocol according to version 2.0 (in particular 2.0A or 2.0B) adapted to be used in the automotive sector and installed in a vehicle 1 (schematically illustrated in FIG. 1). However, what is said here is not limited to the automotive sector but is generally applicable in all sectors in which the use of the CAN protocol is provided. As will become more clear below, the invention can also be implemented in types of networks different from the CAN protocol, and in the associated protocols.

[0020] With respect to Figure 1, each node E 1 -E N is an electronic control unit or ECU belonging to vehicle 1.

[0021] The CAN bus 4 is capable of transmitting different types of messages (or frames), among them: data frames, i.e. frames containing data to be transmitted by a node; remote frames, i.e. frames requesting the transmission of a specific identifier; error frames, i.e. frames transmitted by a node which has detected an error; overload frames, i.e. frames which introduce a delay between data frames and / or remote frames.

[0022] In the context of this disclosure, remote frames, error frames, and overload frames are irrelevant and therefore will not be discussed below.

[0023] Figure 2 shows the sending node E 1 -E N and one or more receiving nodes E 1 -E N1 illustrates a data frame 10 containing data to be transferred between a plurality of data frames 10. In the following, the data frame 10 is also referred to by the term "message". Different messages are usually, but not necessarily, characterized by different types of information content (i.e., the data transmitted).

[0024] The data frame 10 includes, by way of example, the following five fields 10a-10e: - a header field 10a containing one or more subfields used to define, in a manner known per se, the start of a data frame 10 and to manage potential collisions; - a data or payload field 10b containing bytes (from 0 to 8 bytes) representing the information load of a data frame 10 containing useful data transmitted by the node that must be forwarded to the receiving node; - A Cyclic Redundancy Check (CRC) field 10c that contains a check sequence to check for errors contained in the message; - an acknowledgement (ACK) field 10d, which serves as a field for confirmation of receipt by the receiving node; - End Field (EOF) 10e.

[0025] 2 is illustrative of a possible data frame, and it is possible that different versions of the CAN protocol define data frames having different types of fields, however this is irrelevant to the present invention which is applicable to any type of data frame 10 defined according to any version of the CAN protocol.

[0026] 3 illustrates, by way of a flow chart, a procedure for data transmission by a transmitting node over network 2 according to an embodiment of the present invention. A transmission by a transmitting node can have specific nodes as its recipients or can occur in a broadcast mode.

[0027] As a non-limiting example, in the following, one of the nodes of network 2 (e.g., node E 1 ) to a particular receiving node (e.g., node E N ) onto the CAN bus 4. The following description is also applicable by analogy to a transmit broadcast, and in a manner that is clear per se to a person skilled in the art.

[0028] Typically, node E 1 From node E N The transmission of data to node E does not end with the transmission of a single message, but rather multiple messages Msg1-Msg6 are linked together, i.e., node E 1 From node E N The messages Msg1-Msg6 have, by way of example, the format illustrated in Figure 2 and carry respective information data Data1-Data6 in their own payload fields 10b.

[0029] Messages Msg1-Msg6 are sent in the proper order by sending node E. 1 are placed in the queue (send buffer).

[0030] Thus, referring to step 101 of FIG. 3, the sending node E 1 In this step 101, the sending node E sends a subset of the messages Msg1-Msg6, i.e. here the subgroup formed by the messages Msg1, Msg2 and Msg3. 1 However, it is possible for node E to send any number of messages, 2 or more. 1 and E N Obviously, in cases where communication between is completed with a single message, only that single message is sent.

[0031] In the next step 102, the sending node E1 is the receiving node E N In this step 102, the received MAC (MAC 1 ) is calculated as a function of the data Data1-Data3 contained in the payload field 10b of each of the messages Msg1-Msg3 sent in step 101. 1 ) is calculated.

[0032] According to further embodiments, the transmitted MAC code can be calculated based on the content of the entire message in terms of bits or of a predefined subset of the fields or subfields of the message. In the following, for simplicity and without loss of generality, we consider the case where only the payload contributes to the MAC code calculation.

[0033] A frame carrying a MAC code (hereinafter referred to as an "authentication frame") is similar to a data frame, such as data frame 10 of FIG. 2, in terms of the structure or format of the fields that compose it and the number of bytes that are carried. For example, an authentication frame 20 (e.g., the MAC code calculated in step 102) may be used. 1 4, in which an authentication frame 20 (a frame carrying an authentication signal) is illustrated. In at least one embodiment of the present invention, the authentication frame 20 is completely indistinguishable from a data frame as defined by the CAN protocol.

[0034] Specifically, in this example, the authentication frame 20 includes the header field 10a, the cyclic redundancy check field 10c, the acknowledgement field 10d and the end field 10e described above with reference to FIG. 2 and are therefore identified by the same reference numerals; the authentication frame 20 further includes a field 20a which is completely similar to the payload field 10b; however, unlike the data frame 10, the authentication frame 20 includes inside the field 20a the MAC code (MAC 1 Note, however, that the authentication frame 20 is indistinguishable from the data frame 10 in terms of format from the CAN protocol point of view.

[0035] Returning to FIG. 3, in step 103 following step 102, the sending node E 1 sends three further messages Msg4, Msg5, Msg6 to the CAN bus 4 in a manner similar to that performed during step 1.

[0036] Then, in step 104, the sending node E 1 is the receiving node E N to the MAC code (MAC 1 Different MAC 2 ) in field 20a.

[0037] Note that steps 103-104 are duplicates of steps 101-102 and are performed for each message. The procedure illustrated in FIG. 1 may continue indefinitely until it has completed the queue of messages to be sent (and thus performed steps similar to steps 101-102 for all messages to be sent).

[0038] Figure 5 shows the node E N 1 illustrates, by way of example, a flow chart, a procedure for receiving data on a CAN bus 4 by a receiving node.

[0039] In reception, the receiving node E N The messages Msg1-Msg3 (step 201) and the code MAC 1 In the receiving step, the authentication frame 20 (step 202) containing the code MAC 1 But node E 1 The code sent by the MAC 1 Note that the received code may differ from the received code (due to transmission errors or due to fraudulent activity). Therefore, the received code is here denoted as the code MAC. 1 ' to reference it.

[0040] Furthermore, in the receiving step, the messages Msg1-Msg3 and the code MAC 1 (For example, the receiving node E N sends multiple messages and associated authentication frames to different sending nodes E 1 , E 2 Note that the packets may not be completely sequential because they are received from multiple sending nodes E 1 , E 2 When receiving a message from N The receiving buffer of the node E will contain various messages and associated authentication frames 20 in a random order, or in any case in an order that is not predeterminable a priori. However, each message and each authentication frame will contain a common identifier or the identifier of the sending node E that generated it. 1 , E 2 , ... N Each received code MAC 1It is possible to perform the correct ordering for the computation of '.

[0041] Then, the receiving node E N is the received code MAC contained in the field 20a of the authentication frame 20 1 ' is checked for authenticity (step 203); in other words, node E N The MAC code 1 ' corresponds to the expected code, i.e., the code MAC 1 ' is a function (as discussed with reference to the sending step 102) of the data Data1-Data3 of the messages Msg1-Msg3 (MAC 1 '=MAC EXP Ideally, MAC 1 '=MAC EXP =MAC 1 For this purpose, all nodes E of network 2 are encrypted so that a receiving node can always recover the MAC code calculated by a sending node on the basis of the data in the payload field of the message to be sent, based on the data in the payload field of the received message. 1 -E N It is clear that they share a common encryption mechanism (e.g., algorithm).

[0042] After calculating the expected MAC code, the receiving node can perform a comparison with the received MAC code to detect whether they are identical. If they are identical, the associated message is accepted and processed. If they are not identical, countermeasures can be taken, e.g. detecting an incorrect MAC code. 1 The message Msg on which ' was calculated 1 -Msg 3are rejected and an associated error message is sent by the node that detected the error. When the receiving node notices that the same node is sending messages that are repeatedly rejected due to a mismatch between the received MAC code and the expected one (e.g. when the number of messages exceeds a predefined value), the receiving node can decide to consider the sending node as "possibly compromised" and to ignore it for a predefined period of time. After the predefined period of time has elapsed, the receiving node can decide to resume processing messages coming from the sending node.

[0043] Continuing to refer to Figure 5, node E N obtains further messages Msg4-Msg6 in order in step 204 and determines the node E as a function of the data Data4-Data6 of messages Msg4-Msg6. 1 The MAC calculated by 2 Then, in step 206, node E acquires the authentication frame 20 including the code (step 205). N is a code MAC in a manner similar to that described above. 2 Check the authenticity of.

[0044] This procedure is executed on the sending node E 1 This continues until all messages sent by have been received and processed.

[0045] If a hacker or a person with malicious intent or other people writes an unwanted data frame to CAN bus 4, the data frame will be 1 -E N To be accepted by E, they must also know how to generate a MAC code. Indeed, as discussed above, acceptance by each receiving node of a message addressed to it is always determined by each node E. 1 -E NThe MAC code calculated based on a (secret) algorithm resident within the ACK is then verified as correct. In the absence of such verification and acknowledgment, the receiving node enters an alarm state, as discussed above, and appropriate countermeasures are taken.

[0046] In a non-limiting preferred embodiment of the present invention, the MAC code is calculated using the AES-CMAC encryption algorithm (where AES stands for "Advanced Encryption Standard" and CMAC stands for "Cipher-based Message Authentication Code").

[0047] The AES-CMAC algorithm is known per se and typically utilizes the encryption algorithm AES128 to calculate the MAC code. The AES-CMAC encryption algorithm requires the use of an encryption key K. According to one aspect of the invention, each node E 1 -E N 5, the encryption key K is stored in each node E such that it is possible to calculate the associated MAC code based on the received data and the encryption key K, in order to perform the comparison (steps 203 and 206 in FIG. 5) between the received MAC code and the expected MAC code upon receipt. 1 -E N (i.e., the same key K is stored in the local memory of each node E. 1 -E N (Shared by ).

[0048] According to another aspect of the invention, each transmitting node E 1 -E N and each associated key K 1 -K NTherefore, only a receiving node (or multiple receiving nodes) that is interested in checking the authenticity of a message sent by a particular sending node or that is specifically designed to receive the message and must receive it, has the same key K 1 -K N It is possible to save

[0049] It should be noted that the fact that the AES-CMAC algorithm generates a MAC code having the same length (in bytes) as the data contained in the payload field 10b of the data frame, or a code of greater length, is irrelevant. In fact, in the event that the code generated by the encryption algorithm is expressed in a number of bytes that is too large to be written in the payload of a data frame, it is possible to carry out an operation for truncation of such a MAC code in order to respect the requirement regarding the maximum length of the data that can be transmitted by an authentication frame 20 having a format equal to that of a data frame 10.

[0050] For example, when the data Data1-Data3 transmitted in the payload field 10b of the messages Msg1-Msg3 are expressed in 8 bytes, the code MAC 1 can also be represented in 8 bytes. In this way, the requirement to have a MAC authentication code that can be transmitted in a data frame 10 defined by the CAN standard and an authentication frame 20 that is completely similar in terms of format is respected.

[0051] In this regard, note that the AES-CMAC standard requires 8 bytes (or a multiple of 8 bytes) for security reasons. If the payload of the message being sent has a size less than 8 bytes, a "padding" operation (i.e., zeros are added) is provided to ensure the required minimum of 8 bytes is completed.

[0052] Generally speaking, for a typical network, the MAC code can have any number of bytes.

[0053] According to a further aspect of the invention, in order to improve the robustness of the proposed method and thus to increase the security of the network 2, it is also possible to calculate the MAC code as a function of further parameters in addition to the data of the payload field 10b of the message under consideration.

[0054] Specifically, according to an embodiment, an incremental monotonic counter is implemented with a number of bytes equal to the number of bytes that can be carried by the payload field 10b, such that valid inputs for the AES-CMAC encryption algorithm are also configurable. For example, when the payload field 10b is capable of carrying 8 bytes, the monotonic counter is implemented with 8 bytes. Note that 8 bytes is sufficient to cover the entire operational life of the vehicle 1 in which the monotonic counter is implemented. For example, by incrementing the monotonic counter by 1 every second, 2 64 After 10 seconds, the maximum value that can be represented by 8 bytes is reached, which is 584 × 10 9 It corresponds to a length of more than one year.

[0055] As stated earlier, this monotonic counter can be represented in any number of bytes for general networks (not necessarily 8 bytes).

[0056] FIG. 6A illustrates the above description of the transmitting node E 1 The operations performed by the are graphically illustrated using a functional block diagram.

[0057] FIG. 6B shows the node E receiving the above description. N The operations performed by the are graphically illustrated using a functional block diagram.

[0058] Referring to FIG. 6A, the operations illustrated include a transmitting node E having its own controller or processor and local memory, suitably configured to implement the CAN protocol and the encryption operations described. 1 Block 40 of FIG. 6A represents the input of the AES-CMAC encryption algorithm, which is executed by node E 1 The data contents Data1-Data3 (payload field 10b) of the three messages Msg1-Msg3 sent consecutively by node E 1 6A includes the current value MC of a monotonic counter (block 42 in FIG. 6A) that resides within the

[0059] The data Data1-Data3 and the value MC (as mentioned above, all represented as 8 bytes in this example) are input to encryption block 44, which performs the AES-CMAC encryption algorithm discussed above together with an encryption key K stored in local memory (block 46).

[0060] The encryption block 44 is a MAC code (in this example, also an 8-byte MAC 1 --if necessary, a truncation operation is performed) and passes it to block 48 for the generation of the corresponding authentication frame 20. As mentioned above, the authentication frame 20 is indistinguishable from the data frame 10 in terms of format, and therefore the block 48 for generating the authentication frame 20 is identical to that for generating the data frame (and therefore is of a type known per se and will not be described further). Block 48 is connected to the receiving node E. N It also receives data Data1-Data3 to be sent to and generates the associated messages Msg1-Msg3.

[0061] The messages Msg1-Msg3 are written into a transmission queue (or transmission buffer) 50 together with an authentication frame 20 generated based on the data Data1-Data3, and are sent to node E. NThe messages Msg1-Msg3 are sent first, followed by the code MAC 1 An associated authentication frame 20 is transmitted containing:

[0062] Here, the receiving node E N The receiving node receives messages Msg1-Msg3 and codes MAC 1 (or rather the received code MAC, according to the previous explanation) 1 The authentication frame 20 including the ACK / ACK message ') is received and written into the receiving buffer 59.

[0063] Node E N 6A, blocks 40-44. 1 By reproducing the same operations performed in EXP ) locally. Specifically, the receiving node E N obtains (block 60) the data Data1-Data3 contained in the payload fields 10b of the messages Msg1-Msg3, and the current value MC' of a local monotonic counter 62, and passes them to an encryption block 64 which implements the same encryption algorithm as the encryption block 44 (here AES-CMAC).

[0064] The encryption block 64 further receives as input an encryption key K (stored locally in block 65) and converts the received code MAC 1 ' (block 66). This comparison includes the expected MAC code (MAC EXP ) and the received MAC code (MAC 1 The result of the comparison (OK = valid / NOT OK = invalid) determines the action to be taken subsequently.

[0065] The above description applies to subsequent transmissions / receptions, e.g. 2 The procedure applies in an analogous manner for the transmission / reception of three further messages Msg4-Msg6 with associated authentication frames 20 carrying the codes.

[0066] The use of a monotonic counter serves to ensure the "freshness" of the received data as well as the integrity of the encryption. Indeed, it may happen that a hacker or someone with malicious intent could capture multiple data frames with associated authentication frames 20 and rewrite such data frames and associated authentication frames 20 (formally correct) to the CAN bus 4 at a later point in the life of the vehicle 1, resulting in unpredictable errors. However, the presence of a monotonic counter precludes such a possibility, since the MAC code is always progressive over the operational life of the vehicle 1 as described above, and relies on the current value of the counter changing.

[0067] The procedure described above applies to transmission and reception operations by any node of network 2 and, generally speaking, each node E of network 2 1 -E N Note that each of the CAN buses includes its own controller or processor and local memory suitably configured to implement the encryption / decryption operations (FIGS. 6A, 6B) described with reference to the CAN protocol and the transmission and reception.

[0068] In addition, each node E 1 -E N implements its own incremental monotonic counter of the type described above.

[0069] To ensure that each receiving node recognizes the authentication frame 20 (and does not confuse it with a general data frame 10), some recognition strategy can be preliminarily defined.

[0070] In that sense, for example, it is possible to write in the header field 10a of the authentication frame 20 an indication relating both to the identification of the frame of that kind and to the number of the preceding message on which the calculation of the corresponding MAC code was based.

[0071] In a different embodiment, all nodes E 1 -E N provides that all three of the above mentioned methods share the same strategy to be adopted for the recognition of an authentication frame 20, i.e. the fact that an authentication frame 20 of that kind is always generated (and therefore always received) after a predefined number of messages (data frames). In the example discussed above, the number of such is equal to 3 (groups Msg1-Msg3 and Msg4-Msg6). However, it is clear that it is possible to define any number (2 or more) of data frames after which an authentication frame 20 is transmitted (and therefore received), in which the transmitted MAC code is calculated based on the data of a predefined number of preceding data frames. In this context, and also in the case of node E, 1 and E N It is clear that in the case where communication between the two is completed with a single message, the transmission of further data frames having zero information content or predefined information and appropriately managed by the receiving node can be provided (until reaching the predefined number of frames required for the generation of the authentication frame 20).

[0072] The above explanation is for sending node E 1 Transmitting and receiving node E by N This is valid if the processing of the information received by starts and ends within a time interval less than the change in the value MC / MC' of the local counter 42, 62. Indeed, if the value MC / MC' of the local counter differs in transmission and reception, the comparison of block 66 of Figure 6B will not give a reliable response.

[0073] Although transmission onto the CAN bus 4 is typically very quick (on the order of a few thousandths of a second), such imperfections can be remedied by employing one or more strategies.

[0074] For example, in a possible embodiment, the count is incremented after a pre-determined time interval (e.g., 2-5 seconds) to ensure that node E always transmits, receives, and processes a frame of interest (including data and associated MAC code) within such time interval. 1 -E N It is possible to configure each local counter.

[0075] In a further embodiment, the receiving node E N is the time interval T preceding the moment of reception of the authentication frame. C During a period (e.g., 2-5 seconds), multiple values ​​MC' of counter 62 can be acquired and stored. Block 64 then calculates, respectively, the received data (Data1-Data3) and the different values ​​MC' provided by counter 62 (i.e., the value that counter 62 assumed at the time of receipt of the authentication frame and the value that counter 62 assumed at the time of receipt of the authentication frame). C The method calculates multiple MAC codes as a function of , and all values ​​assumed in .

[0076] In a further embodiment, the receiving node E N It is possible to obtain and store a number of values ​​MC' of the counter 62 during a time interval centered about the time of reception of the authentication frame 20 or centered about the time of the calculation of the MAC code by block 64. Such a centered time interval is a time interval T C (e.g., 2-5 seconds) and the time interval T following the moment of reception / calculation of the authentication frame. P(e.g., 1-2 seconds); such centered time intervals also include the time of reception and / or calculation of the authentication frame 20. Block 64 then calculates the time intervals T C and time interval T P The method calculates multiple MAC codes as a function of , and all values ​​assumed in .

[0077] Such MAC codes are then fed to a comparison block 66, which obtains them. The comparison is performed by comparing the authentication frame 20 (MAC 1 If the MAC code received with the cipher suite 64 is equal to at least one of the MAC codes calculated by the encryption block 64, then the result is positive (OK).

[0078] Nodes E, which may become out of sync with respect to each other 1 -E N To obviate possible drift in the local monotonic counter of, the present invention provides two possible variants, which are discussed next.

[0079] In the first variant, node E 1 -E N One of the nodes shall assume the role of the master node and the remaining nodes shall assume the role of the slave nodes.

[0080] In this case, the master node transmits to the CAN bus 4 at random or pre-determined times the updated value of its own monotonic counter, MC new Send the updated value of that species, MC new is the current value of the counter, or the value of its own local clock, MC INT_CLOCKIt is possible to calculate the MC_TIME_TIME as a function of the time (e.g. the clock of the controller or processor of the master node) to which a positive offset "OFFSET" of a predetermined or random value, for example equal to a few seconds, in particular between 10 and 20 seconds, can be added:MC_TIME_TIME new =MC INT_CLOCK +OFFSET.

[0081] Slave nodes have the value MC new Receive the new value of their own local counter and set it to the new value MC new For greater security, in a non-limiting embodiment, each slave node updates the received MC new The update is performed only if the value of MC is larger than the value of MC. new If it is not received correctly, there will be an out-of-synchronization between the various nodes of the network (the MAC codes generated by all nodes will be erroneous); the master node can detect this undesirable situation by performing a cross-check with the previous MC value (i.e. the master node can be configured to recognize that a node of the network is using an old MC value that differs from the updated value).

[0082] In order to restore the counter to the correct value, the master node must update the counter in this situation. new Furthermore, if a slave node becomes disconnected from the CAN network or loses synchronization for any reason between updates of the counter value, the master node detects this situation and resends the new value MC new Note that it is possible to restore correct functionality by retransmitting the

[0083] In the second variant, node E 1 -E N There is a "peer-to-peer" configuration between them.

[0084] In this case, all nodes E 1 -E N Similar to the above, a new value of the monotonic counter MC is larger than the current value. new (periodically or at random times):MC new =MC INT_CLOCK +OFFSET. The other node E 1 -E N is the new value MC new Receive the new value MC new Each node in the network updates its counter only if MC is greater than the current value of its own internal counter. In the case of a peer-to-peer configuration, the value MC new If the MC is not received correctly (e.g., some nodes are using old MC values), the nodes using the unupdated MC value will receive the new value MC new In addition, if a node is disconnected from the CAN network or loses synchronization for any reason during the update of the counter value, the value MC new is sent immediately.

[0085] It is noted that in both of the above mentioned variants, the OFFSET value is generated in such a way that it is greater than the maximum propagation delay that can exist on the CAN bus 4, and also taking into account potential processing delays in the sending and receiving steps. It is also advantageous to take into account the time drift of the clocks.

[0086] Furthermore, the counter value MC new Note that such values ​​can be transmitted using a predefined data frame according to the CAN protocol, represented as 8 bytes. In a similar way, if a different protocol is used, this also applies to represent the counter value MC in the appropriate number of bytes according to the specification of the protocol used.

[0087] Value MC newThe transmission of can occur by using a dedicated message (for example having the same structure as the data frame in a manner similar to the above description of the MAC code); in the MAC calculation of the receiving step, the value MC new is used directly.

[0088] In one embodiment, the code MC new Frames containing this information are configured with a higher priority compared to normal data frames.

[0089] FIG. 7A (where elements in common with FIG. 6A are identified by the same reference numbers) illustrates the transfer of the value MC using a dedicated message 70, which resembles a data frame. new 1 graphically illustrates the steps for generating and transmitting a

[0090] The counter 42 updates the value MC new 7A represents the input of the AES-CMAC encryption algorithm, and is updated using the OFFSET value (as described above) to generate 1 The data contents Data1 and Data3 (payload field 10b) of the two messages Msg1 and Msg3 sent by new In the case of FIG. 7A, the updated value MC of the monotonic counter 42 is new The updated value MC of the monotonic counter 42 is the value of the data message Msg2 (as in the example of FIG. 6A) that is desired to be shared with other nodes in the network (according to the master / slave or peer-to-peer strategy described above). new This is done by replacing the value MC with an equivalent message that transmits new is treated and transmitted as if it were information data just like data Data2 of FIG. 6A.

[0091] In the receiving step of FIG. 7B (common elements to FIG. 6B are identified by the same reference numbers), the updated value MC new is fed to a local counter 62, which in turn feeds it to block 60, where this value is used for the calculation of the MAC code. In an alternative embodiment, the local counter 62 is bypassed and the updated value MC new can obviously be fed directly to block 60.

[0092] Blocks 60-66 use the value MC instead of Data2. new , the value MC' is replaced by the same value MC new and operates in a manner similar to that described above with reference to FIG. 6B.

[0093] If the comparison performed by block 66 gives a positive answer ("OK"), the new value MC new If the local counter 62 is updated, the receiving node E N A strategy for resynchronization of the

[0094] Based on what has been described and illustrated above, the advantages that can be obtained by the system described herein are apparent.

[0095] 8, there is shown a vehicle 1 including an on-board electronic system 72 used to control an on-board system 74 of the vehicle 1. The vehicle 1 is represented only diagrammatically and may be an automobile, motorcycle, truck, sports car, SUV, recreational vehicle, boat, aircraft, etc. The on-board electronic system 72 and the on-board system 74 are connected in an intercommunicative manner using a communication bus 76, such as the previously described CAN bus 4, and include electronic control units (ECUs). 1 , ECU 2 , , , ECU N --Node E discussed earlier 1 , E 2 , ,E N(corresponding to

[0096] The on-board electronic system 72 may include multiple ECUs in the form of electronic hardware components distributed throughout the vehicle 1 configured to receive inputs from one or more sensors to perform, for example, diagnostic, monitoring, control, reporting operations, and / or other functions. At least two, or all, of the ECUs are connected to one another using a bus 76; each ECU may be programmed to control the on-board systems 72 of the vehicle 1. Each ECU shown as part of the on-board electronic system 72 or on-board system 74 generally includes a microprocessor, a non-volatile memory device storing instructions readable by the microprocessor, and input / output ports (I / O) for sending and receiving data and other control information over the bus 76. These components may vary based on the particular system of the vehicle 1 that the respective ECU controls and the type of bus 76 used. The power and processing sophistication of the microprocessor, the number of I / Os, and the complexity of the instructions or software readable by the microprocessor can be increased or decreased based on the type and function of the vehicle 1. The microprocessor can be any type of device capable of processing electronic instructions, including microcontrollers, host processors, controllers, communication processors for vehicles, and application specific integrated circuits (ASICs). The microprocessor executes various types of digitally stored instructions, such as software or firmware programs stored in a memory device. For example, the microprocessor can execute programs or process data to perform at least a portion of the methods discussed above with reference to Figures 3, 5, 6A, and 6B.The memory devices may be implemented using known types of random access memory (RAM) or EEPROM memory, and the I / O may be implemented using a controller, such as a CAN controller, or some other means depending on the type of bus 76 used. In this sense, an ECU may include hardware that is compatible with the particular type of bus 76 used on the vehicle 1. For example, an ECU that communicates using a CAN bus may include a microprocessor, a CAN controller, and an I / O unit in the form of a transceiver that sends and receives messages on the CAN bus.

[0097] In particular, the present invention proposes a method and system for secure and implementable communication between the nodes of the network (in particular between the ECUs of the vehicle) without modifying the current architectural configuration of the network and the vehicle, and without requiring the use of new communication technologies that do not form part of the protocol standards on which the operation of the network is based. The implementation costs are therefore also particularly reasonable.

[0098] Finally, it is evident that modifications and variations to what has been described and illustrated herein can be made without departing from the scope of protection of the invention as defined in the appended claims.

[0099] In particular, the invention is applicable to types of transmission networks different from the CAN bus, e.g. networks based on the CAN-FD protocol, networks based on the TCP / IP protocol, Local Interconnect Network (LIN), Media Oriented Serial Transport (MOST), Ethernet, Local Area Network (LAN), etc.

[0100] In particular, the invention can be applied to wired or wireless transmission networks.

[0101] In addition, although the AES-CMAC encryption method is explicitly mentioned, different encryption methods and algorithms can be used, such as HMAC ("Keyed-Hash Message Authentication Code"), KMAC ("KECCAK Message Authentication Code"), GMAC ("Galois Message Authentication Code"), or others, such as DAA, CBC-MAC, NMAC, OMAC / CMAC, PMAC, VMAC, UMAC, Poly1305, SipHash, etc., and even other algorithms.

[0102] Furthermore, it is clear that the encryption algorithms that can be used to generate the MAC code can be of various types; for example, a symmetric encryption algorithm (where the encryption key K is shared by all nodes E 1 -E N (The public key is stored in E) or asymmetric encryption algorithms (the public key is stored in E 1 -E N and the private key is available at a single node).

[0103] Instead, as illustrated below, each node has a different secret key K 1 , K 2 , ,K N and the associated public key P 1 , P 2 , , P N It is possible to provide this to all nodes. Node E 1 :(K 1 , P 2 , , P N ), Node E 2 :(K 2 , P 1 , P 3 , , P N ), ... Node E N :(K N , P 1 , P 2 , , P N-1 ). [Explanation of symbols]

[0104] 1. Vehicles 2. Networks, communication networks 4 Bus, CAN bus 10 Data Frames 10a Header Fields 10b Payload field, data field 10c CRC field, Cyclic Redundancy Check field 10d ACK field, Acknowledgement field 10e EOF field, end field 20 Authentication Frame 20a Field 40 blocks 42 Counters, Blocks, and Monotonic Counters 44 Encryption Blocks 48 blocks 50 transmit queues, transmit buffers 59 Receive Buffer 60 blocks 62 Local Monotonic Counter, Counter, Local Counter 64 blocks, encrypted blocks 65 blocks 66 blocks, comparison blocks 70 Dedicated Messages 72 On-board electronic systems 74 On-Board Systems 76 Bus, communication bus 10a-10e Field E 1 node E N node Msg1-Msg6 Messages

Claims

1. A method for data exchange in a communication network (2) operating according to a send / receive protocol, said communication network comprising a send bus (4) and a first node (E １ ) and a second node (E Ｎ ), the method comprising: １ ) each having a frame format defined by said protocol and each payload field (10b) which is Ｎ constructing first and second data frames (10) including payload fields (10b) containing respective first and second information data (Data1, Data2) to be transmitted to the first data frame (10); a first message authentication code (MAC) as a function of said first and second information data (Data1, Data2) to be transmitted; １ ) and - having a frame format defined by said protocol and including a payload field (20a) and including said first message authentication code (MAC) in said payload field (20a); １ constructing a third data frame (20) including - transmitting said first, said second and said third data frames onto said transmission bus (4); and further comprising: Ｎ ) receiving said first, said second and said third data frames (10, 20) from said transmission bus (4); - extracting the first information data (Data1) from the received first data frame (10), the second information data (Data2) from the received second data frame (10), and the first message authentication code (MAC) from the received third data frame (20); １ , M.A.C. １ ') and a second message authentication code (MAC) as a function of the extracted first and second information data (Data1, Data2); ＥＸＰ ) and The extracted first message authentication code (MAC １ , M.A.C. １ '), and the calculated second message authentication code (MAC ＥＸＰ ) and The extracted first message authentication code (MAC １ , M.A.C. １ The second message authentication code (MAC ＥＸＰ accepting said first and second data frames (10) only if they are identical to The method includes:

2. The first message authentication code (MAC １ The step of calculating the first message authentication code (MAC) as a function of the encryption key (K) further comprises: １ ) The second message authentication code (MAC ＥＸＰ The step of calculating the second message authentication code (MAC) as a function of the decryption key (K) further comprises: ＥＸＰ ) wherein the encryption key corresponds to the decryption key and thus implements a symmetric encryption algorithm; Alternatively, the encryption key is a private key and the decryption key is a public key that is different from the encryption key, thus implementing an asymmetric encryption algorithm. The method of claim 1.

3. The first message authentication code (MAC １ The step of calculating the first node (E) further comprises: １ ) as a function of a first count value (MC) provided to １ ) The second message authentication code (MAC ＥＸＰ The step of calculating the second node (E Ｎ ) as a function of a second count value (MC') provided to ＥＸＰ ) The first message authentication code (MAC １ , M.A.C. １ The second message authentication code (MAC') is generated only if the first and second information data to be transmitted are identical to the extracted first and second information data and the first count value (MC) is identical to the second count value (MC'). ＥＸＰ ) is the same as The method according to claim 1 or 2.

4. The second message authentication code (MAC ＥＸＰ The step of calculating the second node's (E) from the second incremental monotonic counter (62) during a time frame preceding the time of receiving the second value (MC') further comprises: Ｎ ) with respect to one or more further count values ​​(MC′) provided to The method further comprises: said second node (E Ｎ ) calculating one or more further message authentication codes as a function of each of said one or more further count values ​​(MC'); said second node (E Ｎ ), the extracted first message authentication code (MAC １ , M.A.C. １ ') with each of the one or more further message authentication codes; the second node (E) if and only if the extracted first message authentication code (MAC1, MAC1′) is identical to at least one of the one or more further message authentication codes; Ｎ ) receiving said first and second data frames (10); The method of claim 3, comprising:

5. The method of claim 3 or 4, further comprising the step of synchronizing the first and second incremental monotonic counters (42, 62) with each other.

6. 6. The method of claim 5, wherein the step of synchronizing the first and second incremental monotonic counters (42, 62) with each other comprises the steps of: setting one of the first and second nodes as a master node and the other of the first and second nodes as a slave node; transmitting a synchronization signal by the master node to the transmission bus (4); receiving the synchronization signal from the transmission bus (4) by the slave node; and updating a value of the corresponding first or second incremental monotonic counter (42, 62) of the slave node as a function of the received synchronization signal.

7. 6. The method of claim 5, wherein the step of synchronizing the first and second incremental monotonic counters (42, 62) with each other comprises the steps of: transmitting, by any one of the first and second nodes, a synchronization signal to the transmission bus (4); and receiving, by the other of the first and second nodes, the synchronization signal from the transmission bus (4) and updating the value of the corresponding first or second incremental monotonic counter (42, 62) as a function of the received synchronization signal.

8. The first message authentication code (MAC １ The method of claim 1 , wherein the step of calculating ≠ ≠ ≠ ≠ comprises performing an AES-CMAC encryption algorithm.

9. the protocol is a CAN protocol that defines a frame format for a data type; the first, second, and third data frames all have a frame format identical to the type defined by the protocol; 9. The method according to any one of claims 1 to 8.

10. The transmission bus (4) is a CAN bus of the vehicle (1) and the first node (E １ ) is a first ECU of the vehicle (1), and the second node (E Ｎ 10. The method according to claim 1, wherein the ECU is a second ECU of the vehicle (1).

11. The payload fields (10b, 20a) of the first, second and third data frames (10, 20) are configured to transmit a number of bytes defined by the protocol, and the first and second message authentication codes (MAC １ , M.A.C. ＥＸＰ 11. The method according to claim 1, wherein the number of bytes defined by the protocol is equal to the number of bytes defined by the protocol.

12. A method according to claim 3 or any of claims 4 to 11 when dependent on claim 3, wherein the first and second count values ​​(MC, MC') are expressed in a number of bytes equal to the number of bytes defined by the protocol.

13. A transmission bus (4), a first node (E １ ) and a second node (E Ｎ A data exchange system operating according to a transmission / reception protocol, comprising a communication network (2) including The first node (E １ )but, each having a frame format defined by said protocol and each payload field (10b) which is Ｎ constructing first and second data frames (10) including payload fields (10b) including respective first and second information data (Data1, Data2) to be transmitted to the a first message authentication code (MAC) as a function of the first and second information data (Data1, Data2) to be transmitted; １ ) and - having a frame format defined by said protocol and including a payload field (20a) and including said first message authentication code (MAC) in said payload field (20a); １ ) and - configured to transmit said first, said second and said third data frames onto said transmission bus (4); The second node (E Ｎ )but, receiving said first, said second and said third data frames (10, 20) from said transmission bus (4); - extracting the first information data (Data1) from the received first data frame (10), the second information data (Data2) from the received second data frame (10), and the first message authentication code (MAC) from the received third data frame (20); １ , M.A.C. １ ') and a second message authentication code (MAC) as a function of the extracted first and second information data (Data1, Data2); ＥＸＰ ) and The extracted first message authentication code (MAC １ , M.A.C. １ ') and the second message authentication code (MAC ＥＸＰ ) and The extracted first message authentication code (MAC １ , M.A.C. １ ') is the second message authentication code (MAC ＥＸＰ ) configured to accept said first and second data frames (10) only if they are identical to Data exchange system.

14. The first node (E １ ) further comprises a first message authentication code (MAC) as a function of a cryptographic key (K). １ ) The second node (E Ｎ ) further comprises generating the second message authentication code (MAC) as a function of the encryption key (K). ＥＸＰ ) The system of claim 13.

15. Furthermore, the first node (E １ a first incremental monotonic counter (42) associated with said second node (E Ｎ and a second incremental monotonic counter (62) associated with said first incremental monotonic counter (62), The first node (E １ ) further comprises: a first message authentication code (MAC) as a function of a first count value (MC) provided by the first incremental monotonic counter (42); １ ) The second node (E Ｎ ) further comprises: a second message authentication code (MAC) as a function of a second count value (MC') provided by the second incremental monotonic counter (62); ＥＸＰ ) The second node (E Ｎ ) further comprises: a first message authentication code (MAC) extracted only if the first and second information data to be transmitted are identical to the extracted first and second information data and the first count value (MC) is identical to the second count value (MC'); １ , M.A.C. １ ') and the second message authentication code (MAC ＥＸＰ ) 15. A system according to claim 13 or 14.

16. The second node (E Ｎ ) further states, said second message authentication code (MAC) being calculated with respect to one or more further count values ​​(MC') provided by said second incremental monotonic counter (62) during a time frame preceding and / or following the time of receiving said second value (MC'). ＥＸＰ ), and calculating one or more further message authentication codes as a function of each of said one or more further count values ​​(MC'); The extracted first message authentication code (MAC １ , M.A.C. １ ') with each of the one or more further message authentication codes; and The extracted first message authentication code (MAC １ , M.A.C. １ and configured to accept the first and second data frames (10) only if the first and second message authentication codes (11') are identical to at least one of the one or more further message authentication codes. The system of claim 15.

17. 17. The system of claim 15 or 16, wherein the first and second incremental monotonic counters (42, 62) are synchronized with each other.

18. one of the first and second nodes is configured as a master node and the other of the first and second nodes is configured as a slave node to synchronize the first and second incremental monotonic counters (42, 62) with each other; The master node is further configured to transmit a synchronization signal onto the transmission bus (4); the slave node is further configured to receive the synchronization signal from the transmission bus (4) and to update the value of its first or second incremental monotonic counter (42, 62) as a function of the received synchronization signal.

17. The system of claim 16.

19. The first and second nodes operate in a peer-to-peer type system, and in order to synchronize the first and second incremental monotonic counters (42, 62) with each other, the first and second nodes: transmitting respective first and second synchronization signals including said first and second count values, respectively, onto said transmission bus (4); receiving the other of the first and second synchronization signals from the transmission bus (4); updating, by the first node, its first incremental counter with the second count value only if the second count value is greater than its first count value; configured by the second node to update its second incremental counter with its first count value only if its first count value is greater than its second count value; 20. The system of claim 17.

20. The first node (E １ ) further derives said first message authentication code (MAC) by executing an AES-CMAC encryption algorithm. １ 20. The system of claim 13, configured to calculate

21. the protocol is a CAN protocol that defines a frame format for a data type; the first, second, and third data frames all have a frame format identical to the type defined by the protocol; 21. A system according to any one of claims 13 to 20.

22. The transmission bus (4) is a CAN bus of the vehicle (1) and the first node (E １ ) is a first engine control unit, or ECU, of the vehicle (1), and the second node (E Ｎ 22. A system according to any of claims 13 to 21, wherein the second engine control unit or ECU of the vehicle (1) is a second engine control unit or ECU.

23. The payload fields (10b, 20a) of the first, second and third data frames (10, 20) are configured to transmit a number of bytes defined by the protocol, and the first and second message authentication codes (MAC １ , M.A.C. ＥＸＰ 23. The system according to claim 13, wherein: a) is expressed in a number of bytes equal to the number of bytes defined by the protocol.

24. A system according to claim 15 or any of claims 16 to 23 when dependent on claim 15, wherein the first and second count values ​​(MC, MC') are expressed in a number of bytes equal to the number of bytes defined by the protocol.

25. A vehicle (1) comprising a system for data exchange according to any of claims 13 to 24.

Images