A method and system for data exchange over a network to enhance network security measures, and a vehicle encompassing such a 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 of related applications This patent application claims priority to Italian Patent Application No. 102019000023544, filed on 10 December 2019, and all disclosures of said application are incorporated herein by reference.

[0002] The present invention relates to a method and system for data exchange over a communication network, particularly for enhancing the security of data transmitted over a network, and to a vehicle encompassing such a system. [Background technology]

[0003] Modern electronic systems for automobiles utilize software that operates on electronic control units (ECUs) that communicate with each other within a network via serial buses and gateways. Most current systems are not designed with consideration for the security of onboard data against internal or external attacks that may be generated with the intent to alter exchanged data and cause malfunctions, alterations to motor control applications, and / or crashes of vehicle applications.

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

[0005] However, security-related aspects are hardly considered during the development of hardware and software architectures; at the same time, standard communication protocols also do not provide a shared method for preventing or mitigating attacks.

[0006] Onboard vehicle communication networks are ultimately vulnerable to relatively simple unauthorized access because all communication between ECUs within the vehicle is performed without sufficient authentication mechanisms to ensure that the identity of the sender and receiver remains intact.

[0007] Unfortunately, current communication network protocols such as CAN (Controller Area Network), FlexRay, MOST, and LIN, to name a few, either do not require authentication or, at best, only have an error control mechanism (CRC) to guarantee data integrity, and messages are transmitted in plain text.

[0008] Therefore, there is a possibility of unauthorized communication between control units.

[0009] In particular, with regard to the CAN protocol, various solutions have been proposed to overcome the shortcomings mentioned above, with the aim of improving security, especially in terms of message authenticity and information freshness.

[0010] For example, Non-Patent Document 1 proposes a re-examination of the structure or format of CAN messages to include areas related to control codes. However, such a solution would necessitate general conformity of the implemented protocol, which must allow for the translation of the new message structure.

[0011] Other technical solutions involve introducing new messages with control functions adapted to transmit control information calculated with respect to application data contained within the specific message to be protected. See Non-Patent Document 2 for further details, and also see Non-Patent Document 3. However, these solutions are not optimal due to the significant increase in network traffic and computational load.

[0012] A further solution involves the use of a more recently introduced CAN protocol called CAN-FD, which increases the possibility of implementing a solution aimed at optimizing data transmission and thus improving security, with increased data rates (>1 megabit / second) and payloads (>8 bytes). However, this solution has the drawback of requiring the refitting of the onboard vehicle data exchange system, necessitating conversion to the new protocol, and thus incurring the resulting costs. [Prior art documents] [Non-patent literature]

[0013] [Non-Patent Document 1] "Security Authentication System for In-Vehicle Network" by Hiroshi Ueda et al., 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, Vol. 67, No. 5, May 2018. [Overview of the project] [Problems that the invention aims to solve]

[0014] The object of the present invention is to provide a solution to the aforementioned drawbacks that enables increased security of information transferred between ECUs belonging to the same vehicle network in an efficient and cost-effective manner, without requiring increased computational load and / or modification of hardware resources. [Means for solving the problem]

[0015] Accordingly, the present invention provides a method and system for data exchange over a communication network, as defined in the accompanying claims, and a vehicle encompassing such a system.

[0016] For a better understanding of the present invention, preferred embodiments will be described below with reference to the following accompanying drawings, as non-limiting examples. [Brief explanation of the drawing]

[0017] [Figure 1] This diagram provides a schematic illustration of the network between nodes belonging to the data transmission / reception network implemented within a vehicle. [Figure 2]This diagram illustrates the data frames exchanged between nodes in the network shown in Figure 1. [Figure 3] Figure 1 is a flowchart illustrating the transmission method implemented by the network nodes. [Figure 4] This diagram illustrates the authentication frames exchanged between nodes in the network shown in Figure 1. [Figure 5] Figure 1 is a flowchart illustrating the reception process as implemented by the network nodes. [Figure 6A] This is a functional block diagram illustrating the operations performed by the nodes in the network shown in Figure 1 during the transmission step. [Figure 6B] This is a functional block diagram illustrating the operations performed by the nodes in the network shown in Figure 1 during the receiving step. [Figure 7A] This is a functional block diagram illustrating the operations performed by the nodes in the network shown in Figure 1 during the synchronization step of a local monotonic counter. [Figure 7B] This is a functional block diagram illustrating the operations performed by the nodes in the network shown in Figure 1 during the synchronization step of a local monotonic counter. [Figure 8] This diagram provides a schematic illustration of the vehicles that comprise the network shown in Figure 1. [Modes for carrying out the invention]

[0018] Figure 1 schematically shows communication network 2 operating according to the transmit / receive protocol. Network 2 consists of multiple nodes E1, E2, ..., E N This includes bus 4 to which it is connected (in which case, E N represents the Nth node; however, N is selected according to the specific needs of the application.

[0019] In one embodiment of the present invention, the transmission protocol is of the CAN ("Controller Area Network") type. In this case, bus 4 is a CAN bus. In the context of the present invention, we explicitly refer to the CAN protocol according to version 2.0 (in particular, 2.0A or 2.0B) adapted for use in the automotive sector and installed in vehicle 1 (descriptively illustrated in Figure 1). However, what is stated herein is not limited to the automotive sector and is generally applicable to all sectors where the use of the CAN protocol is provided. As will become more apparent below, the present invention can also be implemented in types of networks and related protocols other than the CAN protocol.

[0020] Regarding Figure 1, each node E1-E N However, it is an electronic control unit or ECU belonging to vehicle 1.

[0021] CAN bus 4 is capable of transmitting different types of messages (or frames), including: data frames, i.e., frames containing data 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 that has detected an error; and overload frames, i.e., frames that introduce delays between data frames and / or remote frames.

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

[0023] Figure 2 shows the transmission nodes E1-E N and one or more receiving nodes E1-E NThis diagram illustrates data frame 10, which contains the data to be transmitted between the two parties. Hereafter, data frame 10 will also be referred to as "message." Different messages are usually, though not necessarily, characterized by different types of informational content (i.e., the data being transmitted).

[0024] Data frame 10, as an example, includes the following five fields 10a-10e: - A header field 10a containing one or more subfields used to define the start of the data frame 10 in a well-known manner 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 to be transmitted by the node, which must be forwarded to the receiving node; - Cyclic Redundancy Check (CRC) field 10c, which includes a check sequence to check for errors contained within the message; - An acknowledgment (ACK) field 10d acts as a field for the receiving node to confirm receipt; - End Field (EOF) 10e.

[0025] The example illustrated in Figure 2 illustrates possible data frames, and different versions of the CAN protocol can define data frames with 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] Figure 3 illustrates a procedure for data transmission on network 2 by a transmitting node according to one aspect of the present invention, using a flowchart. Transmission by a transmitting node can have a specific node as its receiver, or it can occur in broadcast mode.

[0027] As a non-limiting example, in the following, one of the nodes of network 2 (for example, node E1) transmits a plurality of messages Msg1 - Msg6 directed to a specific receiving node (for example, node E N ) to CAN bus 4. The following description is applicable to transmission broadcasts by analogy and in a manner that is obvious to those skilled in the art in this field.

[0028] Normally, the transmission of data from node E1 to node E N does not end with the transmission of a single message, but a plurality of messages Msg1 - Msg6 are grouped together and transmitted in sequence from node E1 to node E N . By way of example, messages Msg1 - Msg6 have the form illustrated in FIG. 2 and each transmits its respective information data Data1 - Data6 within its own payload field 10b.

[0029] Messages Msg1 - Msg6 are placed in the queue (transmission buffer) of the transmitting node E1 in order to be transmitted in the appropriate order.

[0030] Thus, referring to step 101 of FIG. 3, the transmitting node E1 transmits a subset of messages Msg1 - Msg6, that is, a subgroup formed here by messages Msg1, Msg2, and Msg3. In this step 101, the transmitting node E1 can transmit any number of two or more messages. When the communication between nodes E1 and E N is completed with a single message of that kind, it is clear that only that single message of that kind is transmitted.

[0031] In the next step 102, the transmitting node E1 is the receiving node E NNext, a control message called a "Message Authentication Code" (MAC) is sent. In this step 102, the sent MAC (identified as MAC1) is calculated as a function of the data Data1-Data3 contained within the respective payload fields 10b of the messages Msg1-Msg3 sent in step 101.

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

[0033] A frame that transmits a MAC code (hereinafter referred to as an "authentication frame") is similar to a data frame, for example, data frame 10 in Figure 2, in terms of the structure or format of its constituent fields and the number of bytes transmitted. See, for example, Figure 4, which illustrates authentication frame 20 (for example, a frame that transmits MAC1 calculated in step 102). In at least one embodiment of the present invention, authentication frame 20 is completely indistinguishable from a data frame 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 acknowledgment field 10d, and the end field 10e, as described above with reference to Figure 2, and is therefore identified by the same reference number; the authentication frame 20 further includes a field 20a that is completely similar to the payload field 10b; however, unlike the data frame 10, the authentication frame 20 includes a byte (in this case, 8 bytes) inside field 20a that identifies the MAC code (MAC1) calculated in step 102. Note, however, that the authentication frame 20 is indistinguishable from the data frame 10 in terms of format from the perspective of the CAN protocol.

[0035] Returning to Figure 3, in step 103 following step 102, the transmitting node E1 sends three additional messages Msg4, Msg5, and Msg6 to the CAN bus 4 in a manner similar to that performed during step 1.

[0036] Subsequently, in step 104, the transmitting node E1 receives the receiving node E N Next, a new authentication message 20 is sent, which contains in field 20a a MAC code (MAC2, different from MAC1) calculated as a function of the data Data4-Data6 contained in the respective payload fields 10b of the messages Msg4-Msg6 sent in step 103.

[0037] Note that steps 103-104 are duplicates of steps 101-102 and are performed for each message. The procedure illustrated in Figure 3 can continue indefinitely until the sending node E1 completes the queue of messages to be sent (and thus performs steps similar to steps 101-102 for all messages to be sent).

[0038] Figure 5 shows node E here. NThe procedure for receiving data on CAN bus 4 by a receiving node is illustrated using a flowchart.

[0039] In receiving, the receiving node E N However, messages Msg1-Msg3 (step 201) and an authentication frame 20 containing code MAC1 (step 202) are obtained. Note that in the receiving step, the code MAC1 transmitted by the authentication frame 20 may differ from the code MAC1 sent by node E1 (due to a transmission error or unauthorized activity). Therefore, the received code is referred to here by the code MAC1'.

[0040] Furthermore, in the receiving step, messages Msg1-Msg3 and code MAC1 are received (for example, at receiving node E N Note that the messages and associated authentication frames may not be perfectly sequential because the receiving node E1, E2, ... are receiving multiple messages from different sending nodes E1, E2, ... N The receive buffer will contain a variety of messages and associated authentication frames 20 in a random order, or in any case, in an order that cannot be predetermined. However, since each message and each authentication frame carries a common identifier or the identifier of the sending node E1, E2, ... that generated it (in particular, the source address of the sending node), the receiving node E N This makes it possible to perform the correct ordering for calculating each received code MAC1'.

[0041] Subsequently, receiving node E N Step 203 checks the authenticity of the received code MAC1' contained in field 20a of the authentication frame 20; in other words, node E NThis checks whether the code MAC1' corresponds to the expected code, that is, whether the code MAC1' is a function of the data Data1-Data3 of the message Msg1-Msg3 (as discussed with reference to transmission step 102) (MAC1'=MAC EXP Ideally, MAC1' = MAC EXP =MAC1). For this purpose, all nodes E1-E of Network 2 are configured to ensure that the receiving node can always reconstruct the MAC code calculated by the sending node based on the data in the payload field of the message to be sent, based on the data in the payload field of the received message. N It is clear that they share a common encryption mechanism (e.g., an algorithm).

[0042] The receiving node can calculate the expected MAC code and then compare it with the received MAC code to determine if they are exactly the same. If they are exactly the same, the relevant message is accepted and processed. If they are not exactly the same, a corrective action can be taken; for example, messages Msg1-Msg3, which formed the basis for calculating the incorrect code MAC1', are rejected, and the associated error message is sent by the node that detected the error. If the receiving node recognizes that the same node is sending messages that are repeatedly rejected due to a mismatch between the received MAC code and the expected one (for example, when the number of messages exceeds a predetermined value), the receiving node may consider the sending node to be "potentially corrupted" and decide to ignore it for a predetermined period of time. After that predetermined period has elapsed, the receiving node may decide to resume processing messages arriving from that sending node.

[0043] Continuing to refer to Figure 5, node E NIn step 204, the node E sequentially obtains further messages Msg4-Msg6 and obtains an authentication frame 20 containing the MAC2 code calculated by node E1 as a function of the data Data4-Data6 of messages Msg4-Msg6 (step 205). Subsequently, in step 206, node E N This checks the authenticity of code MAC2 in a manner similar to the previous explanation.

[0044] This procedure continues until all messages sent by sending node E1 have been received and processed.

[0045] If a hacker, a person with malicious intent, or someone else writes an unwanted data frame to CAN bus 4, and the written data frame is located at node E1-E N In order to be accepted, those entities must also know how to generate MAC codes. In fact, as discussed above, the acceptance of a message addressed to itself by each receiving node is always performed by each node E1-E N The MAC code, calculated based on an internally resident (confidential) algorithm, undergoes verification to confirm its correctness. If such verification and acknowledgment are not received, 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 (wherein AES stands for "Advanced Encryption Standard" and CMAC stands for "Cipher-based Message Authentication Code").

[0047] The AES-CMAC algorithm is well known in itself and typically uses the AES128 encryption algorithm to compute the MAC code. The AES-CMAC encryption algorithm requires the use of encryption key K. According to one aspect of the present invention, each node E1-E N However, in order to perform a comparison between the received MAC code and the expected MAC code upon reception (steps 203 and 206 in Figure 5), the encryption key K is connected to each node E1-E so that the relevant MAC code can be calculated based on the received data and the encryption key K. N It is stored in the local memory of each node E1-E N (Shared by)

[0048] According to another aspect of the present invention, each transmitting node E1-E N Each of the keys K1-K associated with it N This is provided; therefore, the same key K1-K is only available to receiving nodes (or multiple receiving nodes) that are specifically designed as receiving nodes for messages and must receive them, or who are interested in checking the authenticity of messages sent by a particular sending node. N It is possible to save it.

[0049] It should be noted that the fact that the AES-CMAC algorithm generates a MAC code that is the same length (in bytes) as the data contained in the payload field 10b of the data frame, or a longer code, is irrelevant. In fact, if the code generated by the encryption algorithm is represented in a number of bytes that is too large to be written into the payload of the data frame, it is possible to perform an operation to truncate that type of MAC code in order to respect the requirement regarding the maximum length of data that can be transmitted by the authentication frame 20 having a format equivalent to that of the data frame 10.

[0050] This means, for example, that if the data Data1-Data3 transmitted within the payload field 10b of messages Msg1-Msg3 are represented by 8 bytes, then the code MAC1 calculated by the AES-CMAC algorithm based on Data1-Data3 can also be represented by 8 bytes. In this way, the requirement that the MAC authentication code be able to be transmitted within an authentication frame 20 that is completely similar in format to the data frame 10 defined by the CAN standard 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 is smaller than 8 bytes, a "padding" operation (i.e., zeros are added) is provided to ensure that the required minimum of 8 bytes is met.

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

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

[0054] Specifically, according to the embodiment, an incremental monotonic counter is implemented, represented by a number of bytes equal to the number of bytes that can be transmitted by the payload field 10b, so that a valid input for the AES-CMAC encryption algorithm can also be configured. For example, when the payload field 10b has the capability to transmit 8 bytes, the monotonic counter is implemented with 8 bytes. Note that 8 bytes are sufficient to cover the entire operating life of vehicle 1 in which the monotonic counter is implemented. For example, by increasing the monotonic counter by 1 unit per second, 2 64 After a few seconds, it reaches the maximum value that can be represented by 8 bytes, which is 584 × 10 9 Supports lengths exceeding one year.

[0055] As mentioned earlier, this monotonic counter can be represented in any number of bytes for general network purposes (it doesn't have to be 8 bytes).

[0056] Figure 6A graphically illustrates the operations performed by the transmitting node E1, as described above, using a functional block diagram.

[0057] Figure 6B shows the above explanation received by node E N The actions performed by this system are graphically illustrated using functional block diagrams.

[0058] Refer to Figure 6A, where the illustrated operation is performed by a transmitting node E1 having its own controller or processor and local memory, and appropriately configured to implement the CAN protocol and the described encryption operation. Block 40 in Figure 6A represents the input to the AES-CMAC encryption algorithm and includes the data contents Data1-Data3 (payload field 10b) of three messages Msg1-Msg3 transmitted sequentially by node E1, as well as the current value MC of a monotonic counter (block 42 in Figure 6A) residing within node E1.

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

[0060] The encryption block 44 generates a MAC code (in this example, an 8-byte MAC1—truncated if necessary) and sends it to block 48 for the generation of the corresponding authentication frame 20. As previously mentioned, the authentication frame 20 is indistinguishable from the data frame 10 in terms of format, and therefore the block 48 that generates the authentication frame 20 is identical to the one that generates the data frame (and is therefore of a well-known type, so no further explanation is needed). Block 48 sends to receiving node E N The system also receives the data Data1-Data3 that should be sent and generates the associated messages Msg1-Msg3.

[0061] Messages Msg1-Msg3, along with authentication frames 20 generated based on data Data1-Data3, are written into the send queue (or send buffer) 50, and Node E N The messages are sequentially sent to CAN bus 4 as recipients. Messages Msg1-Msg3 are sent first, followed by the associated authentication frame 20 containing code MAC1.

[0062] Here, receiving node E N Refer to Figure 6B, which graphically illustrates the actions performed by using a functional block diagram. The receiving node receives messages Msg1-Msg3 and an authentication frame 20 containing code MAC1 (or, as described above, rather the received code MAC1'), and writes them to the receive buffer 59.

[0063] Node E NNext, by referring to blocks 40-44 in Figure 6A, the same operation performed in the transmission node E1 described above is reproduced, thereby obtaining the expected MAC code (MAC). EXP ) is calculated locally. Specifically, the receiving node E N It obtains the data Data1-Data3 contained within the payload field 10b of messages Msg1-Msg3, and the current value MC' of the local monotonic counter 62 (block 60), and sends them to encryption block 64, which performs the same encryption algorithm as encryption block 44 (in this case, AES-CMAC).

[0064] Encryption block 64 further receives the encryption key K (stored locally within block 65) as input and generates as output (block 66) an 8-byte number (possibly with truncation similar to that performed by block 44) which is compared with the received code MAC1'. This comparison involves the expected MAC code (MAC EXP The intention is to evaluate the identity between the received MAC code (MAC1') and the original MAC address. The result of the comparison (OK = valid / NOT OK = invalid) determines the subsequent action to be taken.

[0065] The above description applies in a similar manner to subsequent transmissions / receptions, for example, to the transmission / reception of three further messages Msg4-Msg6, each accompanied by a relevant authentication frame 20 that transmits the relevant MAC2 code.

[0066] The use of a monotonic counter serves to guarantee not only the integrity of encryption but also the "freshness" of the received data. In fact, it is possible that a hacker or someone with malicious intent could obtain multiple data frames along with their associated authentication frames 20, and then rewrite those data frames and associated authentication frames 20 (formally correct) to the CAN bus 4 at a later point in the vehicle's lifespan, causing unpredictable errors. However, the presence of a monotonic counter eliminates this possibility because the MAC code always relies on the current value of a counter that is progressive and changes over the operating lifespan of the vehicle 1, as mentioned above.

[0067] The procedures described above apply to the send and receive operations of any node in Network 2, and generally speaking, to each node E1-E in Network 2. N However, note that it is equipped with its own controller or processor and local memory, appropriately configured to implement the encryption / decryption operations described with reference to the CAN protocol and transmission and reception (Figures 6A, 6B).

[0068] In addition, each node E1-E N It is equipped with 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), it is possible to preliminarily define some recognition strategy.

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

[0071] Different embodiments are available for all nodes E1-E NHowever, it provides the fact that the same strategy should be employed for recognizing the authentication frame 20, namely the fact that that kind of authentication frame 20 is always generated (and therefore always received) after a predetermined number of messages (data frames). In the example discussed above, the number of that kind is equal to 3 (the groups Msg1-Msg3 and Msg4-Msg6). However, it is clear that the number of data frames that subsequently receive the authentication frame 20 can be arbitrarily defined (2 or more), in which the transmitted MAC code is calculated based on the data of the predetermined number of preceding data frames. In this context, and also nodes E1 and E N When communication between them is completed with a single message, it is clear that the transmission of further data frames containing zero-information content or predefined information, which are appropriately managed by the receiving node, is possible (until a predefined number of frames required for the generation of authentication frame 20 is reached).

[0072] The above description applies to transmission by transmitting node E1 and receiving node E N The processing of the information received is valid if it begins and ends within a time interval less than the change in the values ​​MC / MC' of local counters 42 and 62. In fact, if the values ​​MC / MC' of the local counters differ between transmission and reception, the comparison in block 66 of Figure 6B will not provide a reliable response.

[0073] Transmission to CAN bus 4 is generally very fast (in the thousands ofths of a second), but this kind of drawback can be mitigated by employing one or more strategies.

[0074] For example, in a possible embodiment, nodes E1-E are incremented in count units after a predetermined time interval (e.g., 2-5 seconds) to ensure that the transmission, reception, and processing of frames of interest (including data and associated MAC codes) within that time interval are always guaranteed. N It is possible to configure each local counter.

[0075] In a further embodiment, receiving node E N However, the time interval T preceding the time of receiving the authentication frame C It is possible to acquire and store multiple values ​​MC' of counter 62 within a time interval (for example, 2-5 seconds). Block 64 then stores each of the received data (Data1-Data3) and the different values ​​MC' supplied by counter 62 (i.e., the value that counter 62 assumed at the time of receiving the authentication frame, and the value that counter 62 assumed at the time interval T). C Calculate multiple MAC codes as a function of all the assumed values ​​within them.

[0076] In a further embodiment, receiving node E N However, it is possible to acquire and store multiple values ​​MC' of counter 62 during a time interval centered on the time of receiving the authentication frame 20 or on the time of calculating the MAC code by block 64. Such a centered time interval is a time interval T that precedes the time of receiving and / or calculating the authentication frame. C (For example, 2-5 seconds) and the time interval T that follows the time when the authentication frame is received / calculated. P (For example, 1-2 seconds) and the same kind of centralized time interval also includes the time of receiving and / or calculating the authentication frame 20. Block 64 then contains, respectively, the received data (Data1-Data3) and the multiple values ​​MC' supplied by counter 62 (i.e., the value that counter 62 assumed to be at the time of receiving / calculating the authentication frame, and the time interval T) that counter 62 assumed. C and time interval T PCalculate multiple MAC codes as a function of all the assumed values ​​within them.

[0077] Those MAC codes are then fed to comparison block 66, which obtains them. The comparison has a positive result (OK) if the MAC code received with the authentication frame 20 (MAC1' in Figure 6B) is equal to at least one of several MAC codes calculated by encryption block 64.

[0078] Nodes E1-E may be out of sync with each other. N To prevent drift in the local monotonic counter, the present invention offers two possible modifications, which will be discussed below.

[0079] In the first transformation, node E1-E N One of the nodes will act as the master node, and the remaining nodes will act as slave nodes.

[0080] In this case, the master node sends the updated value MC of its own monotonic counter to the CAN bus 4 at random or predetermined times. new Send the updated value MC of that kind. new This is the current value of the counter, or the value of its own local clock MC. INT_CLOCK It is possible to calculate this as a function of (for example, the clock of the master node's controller or processor) and add a positive offset "OFFSET" of a predetermined or random value equal to, for example, a few seconds, especially between 10 and 20 seconds:MC new =MC INT_CLOCK +OFFSET.

[0081] The slave node is value MC new It receives the values ​​of their own local counters and sets them to the new value MC newUpdate to: For higher security, in a non-limiting embodiment, each slave node receives MC from the current value of its own local counter. new The update is performed only if the value is large. The value MC is determined by the slave node. new If the MAC is not received correctly, it will cause a synchronization issue among the various nodes in the network (the MAC codes generated by all nodes will be incorrect); the master node can detect this undesirable situation by performing a cross-check using the preceding MC value (i.e., the master node can be configured to recognize that the nodes in the network are using an old MC value that is different from the updated value).

[0082] To restore the counter to the correct value, the master node, in this situation, updates the value MC new Resend. Furthermore, if the slave node disconnects from the CAN network or loses synchronization for any reason while the counter value is being updated, the master node will detect such a situation and resend the new value MC. new Note that proper functionality can be restored by resending the message.

[0083] In the second transformation, node E1-E N A "peer-to-peer" structure exists between them.

[0084] In this case, all nodes E1-E N However, similar to the above, a new value MC of the monotonic counter is obtained, which is greater than the current value. new Send (at periodic or random times): MC new =MC INT_CLOCK +OFFSET. The other node E1-E N This is the new value MC new Received the new value MC newEach counter is updated only if the value is greater than the current value of its own internal counter. In a peer-to-peer configuration, the value MC is updated by all nodes in the network. new If the MC value is not received correctly (for example, some nodes are using the old MC value), the nodes using the outdated MC value will receive the new MC value. new Resend. In addition, if a node disconnects from the CAN network or loses synchronization for any reason while the counter value is being updated, the value MC will be resent by a node that is unable to correctly calculate the MAC code. new It will be sent immediately.

[0085] In both of the above variations, it should be noted that the OFFSET value is generated in such a manner that it is greater than the maximum propagation delay that can exist on the CAN bus 4, and that potential processing delays in the transmit and receive steps are also taken into consideration. It is also advantageous to take into account the clock's time drift.

[0086] Furthermore, the R&D MC new Note that this is represented by 8 bytes, and such values ​​can be transmitted using predefined data frames according to the CAN protocol. Similarly, when different protocols are used, this represents and applies a counter value MC of the appropriate number of bytes according to the specifications of the protocol used.

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

[0088] One example is Code MC new Frames containing this element are configured with a higher priority compared to regular data frames.

[0089] FIG. 7A (elements common to FIG. 6A are identified by the same reference numerals) graphically illustrates the step of generating and transmitting the value MC using a dedicated message 70 similar to a data frame. new

[0090] The counter 42 is updated using the OFFSET value (as described above) to generate the updated value MC. new Block 40 in FIG. 7A represents the input to the AES-CMAC encryption algorithm and includes the data contents Data1 and Data3 (payload field 10b) of two messages Msg1 and Msg3 transmitted by node E1, and in addition the updated value MC of the monotonic counter (block 42), new in a manner similar to the previous description referring to FIG. 6A. In the case of FIG. 7A, the sharing of the updated value MC of the monotonic counter 42 results in replacing the data message Msg2 (as in the example of FIG. 6A) with an equivalent message that transmits the updated value MC of the monotonic counter 42 whose sharing with other nodes in the network is desired (according to the master / slave or peer-to-peer strategy described above). new In other words, the value MC new is treated and transmitted as if it were information data similar to the data Data2 in FIG. 6A. new

[0091] In the receiving step of FIG. 7B (elements common to FIG. 6B are identified by the same reference numerals), the updated value MC new is supplied to the local counter 62, which then supplies it to block 60, where this value is used for the calculation of the MAC code. In an alternative embodiment, it is clear that the local counter 62 can be bypassed and the updated value MC new can be supplied directly to block 60.

[0092] Blocks 60 - 66 use the value MC instead of Data2​​new is used instead of the value MC’ with the same value MC new and operates in a similar manner as the previous description referring to FIG. 6B.

[0093] If the comparison performed by block 66 gives a positive response (“OK”), the update of the local counter 62 to the new value MC new is confirmed; otherwise, a strategy for resynchronization of the receiving node E N is executed.

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

[0095] Referring to FIG. 8, a vehicle 1 is shown 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 schematically and can be, for example, an automobile, a motorcycle, a truck, a sports car, an SUV, a recreational vehicle, a boat, an aircraft, etc. The on-board electronic system 72 and the on-board system 74 are connected in a manner that they communicate with each other using a communication bus 76, for example, the CAN bus 4 described previously, and include a schematic arrangement of electronic control units (ECU1, ECU2, ···, ECU N -- corresponding to the nodes E1, E2, ···, E discussed previously N ).

[0096] The onboard electronic system 72 may include multiple ECUs in the form of electronic hardware components distributed throughout the vehicle 1, configured to receive input from one or more sensors to perform diagnostic, monitoring, control, reporting operations, and / or other functions. At least two, or all, of the ECUs are connected to each other using a bus 76; each ECU can be programmed to control the onboard system 72 of the vehicle 1. Each ECU shown as part of the onboard electronic system 72 or onboard 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 on the bus 76. These components can be modified based on the specific system of the vehicle 1 that each ECU controls and the type of bus 76 used. The power and processing sophistication of a 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. A 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). Microprocessors execute various types of digitally stored instructions, such as software or firmware programs stored in memory devices. For example, a microprocessor can execute programs or process data to perform at least some of the methods discussed in reference to Figures 3, 5, 6A, and 6B.The memory device can be implemented using well-known types of random-access memory (RAM) or EEPROM memory, and the I / O can 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, the ECU can include hardware compatible with a particular type of bus 76 used on the vehicle 1. For example, an ECU that communicates using a CAN bus can include a microprocessor, a CAN controller, and I / O units in the form of transceivers that send and receive messages on the CAN bus.

[0097] In particular, the present invention proposes a secure and implementable communication method and system that does not alter the current architectural configuration of the network and vehicles between network nodes (especially between vehicle ECUs), and does not require the use of new communication technologies that do not form part of the protocol standards on which the network operation is based. Therefore, the implementation cost is also particularly reasonable.

[0098] Finally, it is clear that modifications and variations to those described and illustrated herein can be carried out without departing from the scope of protection of the present invention as defined in the accompanying claims.

[0099] In particular, the present invention is applicable to transmission networks of types other than the CAN bus, such as networks based on the CAN-FD protocol, TCP / IP protocol, Local Interconnection Network (LIN), Media-Oriented Serial Transport (MOST), Ethernet, Local Area Network (LAN), and so on.

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

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

[0102] Furthermore, it is clear that the cryptographic algorithms available for MAC code generation can be of various types; for example, symmetric cryptographic algorithms (where the encryption key K is used for all nodes E1-E N (stored in) or asymmetric encryption algorithm (public key is stored in all nodes E1-E N It is possible to use the private key (which is stored in a location and available on a single node) on a single node.

[0103] Instead, as will be illustrated below, each node has a different secret key K1, K2, ..., K N And the associated public keys P1, P2, ..., P N It is possible to provide this to all nodes. Node E1:(K1, P2, ..., P N ), Node E2:(K2, P1, P3, ..., P N ), ... Node E N :(K N P1, P2, ..., P N-1 ). [Explanation of Symbols]

[0104] 1. Vehicles 2. Networks, communication networks 4 buses, CAN buses 10 Data Frames 10a Header Field 10b Payload field, data field 10c CRC field, cyclic redundancy check field 10d ACK field, affirmative response field 10e EOF field, end field 20 Authentication Frames 20a Field 40 blocks 42 Counters, Blocks, Monotonic Counters 44 encryption blocks 48 blocks 50 transmit queue, transmit buffer 59 Receive buffer 60 blocks 62 Local monotonic counter, counter, local counter 64 blocks, encryption blocks 65 blocks 66 blocks, comparison blocks 70 Dedicated Message 72 Onboard Electronic Systems 74 Onboard Systems 76 Bus, Communications Bus 10a-10e Field E1 node E N node Msg1-Msg6 Message

Claims

1. A method for data exchange in a communication network (2) operating according to a transmit / receive protocol, wherein the communication network comprises a transmit bus (4) and a first node (E) connected to the transmit bus (4). １ ) and the second node (E Ｎ ) and the method includes the first node (E １ ) is performed by - Each has a frame format defined by the transmission / reception protocol, and each payload field (10b) is the second node (E Ｎ The steps include constructing a first data frame (10) and a second data frame (10) which include a payload field (10b) containing first information data and second information data (Data1, Data2) to be transmitted to ), - The first message authentication code (MAC) is used as a function for the first and second information data (Data1, Data2) to be transmitted. １ The steps of calculating ) and - Having a frame format defined by the transmission / reception protocol, and including a payload field (20a), and containing the first message authentication code (MAC) in the payload field (20a). １ The steps include: constructing a third data frame (20) that includes ) - The steps of transmitting the first data frame, the second data frame, and the third data frame to the transmission bus (4), The method includes, and furthermore, the second node (E Ｎ ) is performed by - The steps of receiving the first data frame, the second data frame, and the third data frame (10, 20) from the transmission bus (4), - Extract 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 １ , MAC １ ’) from the received third data frame (20); - The second message authentication code (MAC) is used as a function for the extracted first information data and second information data (Data1, Data2). ＥＸＰ The steps of calculating ) and - The extracted first message authentication code (MAC １ MAC １ ') and the calculated second message authentication code (MAC ＥＸＰ ) and the step of comparing them, - The extracted first message authentication code (MAC １ MAC １ The second message authentication code (MAC) calculated by ') ＥＸＰ The steps include accepting the first data frame and the second data frame (10) only if they are identical to the first data frame, It includes, The first message authentication code (MAC １ The step of calculating the first count value (MC, MC) by the first node further involves the first node calculating the first count value (MC, MC ｎｅｗ This includes calculating the first message authentication code as a function of ), where the first count value is the count value of the local counter of the first node. The second message authentication code (MAC ＥＸＰ The step of calculating the second count value (MC', MC) by the second node further involves the second node calculating the second count value (MC', MC ｎｅｗ This includes calculating the second message authentication code as a function of ), where the second count value is the count value of the local counter of the second node. moreover, One of the first node and the second node is set as the master node, and the other of the first node and the second node is set as the slave nodes, The master node updates the count value of the local counter of the master node (MC ｎｅｗ ) to supply, The master node transmits the updated count value to the transmit bus. The slave node receives the updated count value, This includes synchronizing the first count value and the second count value by having the slave node update the count value of the local counter of the slave node with the updated count value, The updated count value is a random value, method.

2. The method according to claim 1, wherein the count value of the local counter of the slave node is updated to the updated count value only if the updated count value is greater than the count value of the local counter of the slave node.

3. The method according to claim 1 or 2, wherein the local counter of the master node is a monotonic counter.

4. The method according to any one of claims 1 to 3, wherein the updated count value is calculated by adding a positive random offset to the count value of the local counter of the master node.

5. The first message authentication code (MAC １ MAC １ ') is defined as the first information data and second information data to be transmitted being identical to the extracted first information data and second information data, and the first count value (MC, MC ｎｅｗ ) is the second count value (MC', MC ｎｅｗ The second message authentication code (MAC) is only used if it is identical to the first one. ＥＸＰ The method according to any one of claims 1 to 4, which is identical to ).

6. The first message authentication code (MAC １ The step of calculating the first message authentication code (MAC) as a function of the cryptographic key (K) is further performed. １ This includes calculating ) The second message authentication code (MAC ＥＸＰ The step of calculating the second message authentication code (MAC) as a function of the decryption key (K) is further performed. ＥＸＰ The method according to any one of claims 1 to 5, comprising calculating ).

7. The method according to claim 6, wherein the encryption key corresponds to the decryption key, and therefore implements a symmetric encryption algorithm.

8. The second message authentication code (MAC ＥＸＰ The step of calculating the second count value (MC') further includes the second node (E) during the time frame preceding the time when the second count value (MC') is received. Ｎ This is performed with respect to one or more further count values ​​(MC') supplied to ), The above method further, - The second node (E Ｎ ) a step of calculating one or more further message authentication codes as a function of each of the one or more further count values ​​(MC'), - The second node (E Ｎ In the above, the extracted first message authentication code (MAC １ MAC １ The step of comparing ') with each of the one or more further message authentication codes, - The second node (E) is only performed if the extracted first message authentication code (MAC1, MAC1') is identical to at least one of the one or more further message authentication codes. Ｎ The steps include: ) receiving the first data frame and the second data frame (10), The method according to any one of claims 1 to 7, comprising:

9. The first message authentication code (MAC １ The method according to any one of claims 1 to 8, wherein the step of calculating ) comprises performing the AES-CMAC encryption algorithm.

10. The aforementioned transmission / reception protocol is a CAN protocol that defines the frame format of the data type. The first data frame, the second data frame, and the third data frame all have the same frame format as the data type defined by the transmission / reception protocol. The method according to any one of claims 1 to 9.

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

12. The payload fields (10b, 20a) of the first data frame, the second data frame, and the third data frame (10, 20) are configured to transmit a number of bytes defined by the transmit / receive protocol, and the first message authentication code and the second message authentication code (MAC) １ MAC ＥＸＰ The method according to any one of claims 1 to 11, wherein ) is represented by a number of bytes equal to the number of bytes defined by the transmission / reception protocol.

13. The method according to any one of claims 1 to 12, wherein the first count value and the second count value (MC, MC') are expressed in a number of bytes equal to the number of bytes defined by the transmission / reception protocol.

14. A transmission bus (4), and a first node (E) connected to the transmission bus (4). １ ) and the second node (E) connected to the transmission bus (4) Ｎ A data exchange system that operates according to a transmission / reception protocol including a communication network (2) including, The first node (E １ )but, - Each has a frame format defined by the transmission / reception protocol, and each payload field (10b) is the second node (E Ｎ A first data frame and a second data frame (10) are constructed, each containing a payload field (10b) which includes a first information data and a second information data (Data1, Data2) to be transmitted to the ) - The first message authentication code (MAC) is used as a function for the first information data and the second information data (Data1, Data2) to be transmitted. １ ) calculate, - Having a frame format defined by the transmission / reception protocol, and including a payload field (20a), and containing the first message authentication code (MAC) in the payload field (20a). １ A third data frame (20) is formed including ), and - Configured to transmit the first data frame, the second data frame, and the third data frame to the transmission bus (4), The second node (E Ｎ )but, - The first data frame, the second data frame, and the third data frame (10, 20) are received from the transmission bus (4). - From the received first data frame (10), the first information data (Data1) is extracted; from the received second data frame (10), the second information data (Data2) is extracted; and from the received third data frame (20), the first message authentication code (MAC) is extracted. １ MAC １ Extract ') and - The second message authentication code (MAC) is used as a function for the extracted first information data and second information data (Data1, Data2). ＥＸＰ ) calculate, - The extracted first message authentication code (MAC １ MAC １ ') and the second message authentication code (MAC ＥＸＰ ) and, - The extracted first message authentication code (MAC １ MAC １ ') is the second message authentication code (MAC ＥＸＰ It is configured to accept the first data frame and the second data frame (10) only if they are identical to the first data frame, The first node has a first count value (MC, MC ｎｅｗ The first message authentication code (MAC) is a function of ) １ ) is configured to calculate, where the first count value is the count value of the local counter of the first node, The second node is the second count value (MC', MC ｎｅｗ The second message authentication code (MAC) is a function of ) ＥＸＰ ) is configured to calculate, where the second count value is the count value of the local counter of the second node, In order to synchronize the first count value and the second count value with each other, one of the first node and the second node is configured as the master node, and the other of the first node and the second node is configured as the slave nodes. The aforementioned master node is The updated count value of the local counter of the master node (MC ｎｅｗ ) to supply, The updated count value is configured to be transmitted to the transmission bus. The slave node is Receiving the updated count value, The slave node is configured to update the count value of the local counter to the updated count value. The aforementioned updated count value is a random value. Data exchange system.

15. The system according to claim 14, wherein the count value of the local counter of the slave node is updated to the updated count value only if the updated count value is greater than the count value of the local counter of the slave node.

16. The system according to claim 14 or 15, wherein the updated count value is calculated by adding a positive random offset to the count value of the local counter of the master node.

17. The second node (E Ｎ Furthermore, 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, MC ｎｅｗ ) is the second count value (MC', MC ｎｅｗ The first message authentication code (MAC) extracted only if it is identical to the first message authentication code (MAC) １ MAC １ ') and the second message authentication code (MAC ＥＸＰ ) Constructed to confirm identity between The system according to any one of claims 14 to 16.

18. The second node (E Ｎ ) further, The second message authentication code (MAC) is provided with respect to one or more further count values ​​(MC') supplied during a time frame preceding and / or following the time frame at which the second count value (MC') is received. ＥＸＰ The process of calculating ) is repeated, Calculate one or more additional message authentication codes as a function of each of the one or more additional count values ​​(MC') The extracted first message authentication code (MAC １ MAC １ ') is compared with each of the one or more additional message authentication codes, and, The extracted first message authentication code (MAC １ MAC １ The first data frame and the second data frame (10) are configured to accept them only if ') is identical to at least one of the one or more further message authentication codes. The system according to any one of claims 14 to 17.

19. The first node (E １ ) further executes the AES-CMAC encryption algorithm to obtain the first message authentication code (MAC １ A system according to any one of claims 14 to 18, configured to calculate ).

20. The aforementioned transmission / reception protocol is a CAN protocol that defines the frame format of the data type. The first data frame, the second data frame, and the third data frame all have the same frame format as the data type defined by the transmission / reception protocol. The system according to any one of claims 14 to 19.

21. The transmission bus (4) is the CAN bus of the vehicle (1), and the first node (E １ ) is the first engine control unit, i.e., ECU, of the vehicle (1), and the second node (E Ｎ The system according to any one of claims 14 to 20, wherein the second engine control unit, i.e., ECU, of the vehicle (1).

22. The payload fields (10b, 20a) of the first data frame, the second data frame, and the third data frame (10, 20) are configured to transmit a number of bytes defined by the transmit / receive protocol, and the first message authentication code and the second message authentication code (MAC) １ MAC ＥＸＰ The system according to any one of claims 14 to 21, wherein the number of bytes is represented by the same number of bytes as defined by the transmission / reception protocol.

23. The system according to any one of claims 14 to 22, wherein the first count value and the second count value (MC, MC') are expressed in a number of bytes equal to the number of bytes defined by the transmit / receive protocol.

24. A vehicle (1) including a system for data exchange according to any one of claims 14 to 23.

Images