Improved end-to-end controller protection and message authentication

Abstract

This disclosure provides "improved end-to-end controller protection and message authentication". A first electronic control unit (ECU) communicates with a second ECU via a vehicle bus. The first ECU is configured to generate a functional safety value and a security protection value for a message, verify the security protection value of the message, and send the message, which includes the security protection value but does not include the functional safety value, to the second ECU.

Description

Technical Field

[0001] The various aspects of this disclosure generally relate to systems and methods for protecting communication between electronic control units (ECUs). Background Technology

[0002] Functional safety typically refers to the absence of unreasonable risks arising from the malfunctioning behavior of electrical or electronic systems. Security measures typically involve defensive measures implemented at the network edge or within the network to prevent intruders or other malicious actors from launching attacks or threats on the network. Both functional safety and security measures are useful for protecting systems. However, both increase the overhead and complexity of the system. Summary of the Invention

[0003] In one or more illustrative examples, the system includes a first electronic control unit (ECU) that communicates with a second ECU via a communication bus. The first ECU is configured to generate security protection values ​​for messages (e.g., counters, checksums, freshness, and message authentication code (MAC) values), verify end-to-end (E2E) communication protection values ​​for messages (e.g., counters and checksums), and send messages that include security communication protection values ​​(e.g., freshness and MAC) but not E2E communication protection values ​​(e.g., counters and checksums) to the second ECU.

[0004] In one or more illustrative examples, a method includes: generating a counter and checksum value for a message by a first electronic control unit (ECU); verifying the counter and checksum value by the first ECU; sending the message, which includes a freshness and a network interface identifier value but excludes the counter and checksum value, to a second ECU; regenerating the counter and checksum value by the second ECU; and verifying the regenerated counter and checksum value by the second ECU.

[0005] In one or more illustrative examples, a non-transitory computer-readable medium includes instructions that, when executed by a processor of a first ECU communicating with a second electronic control unit (ECU) via a vehicle bus, cause the first ECU to generate a message counter, checksum, freshness, and message authentication code (MAC) value, verify the message counter and checksum value, and send the message, including the freshness and MAC value but excluding the counter and checksum value, to the second ECU. Attached Figure Description

[0006] Figure 1 An exemplary system is shown that includes a vehicle implementing functional safety measures and safety measures;

[0007] Figure 2 An exemplary diagram is shown, illustrating the configuration of an ECU for communication via a communication bus;

[0008] Figure 3 An exemplary diagram of the information sent by the ECU is shown;

[0009] Figure 4 An exemplary diagram illustrating communication between two ECUs in a broadcast network system is shown;

[0010] Figure 5 An exemplary diagram illustrating the details of communication between the two ECUs of the system;

[0011] Figure 6 An exemplary diagram showing a standalone model of functional safety measures and safety measures is provided;

[0012] Figure 7 An exemplary diagram illustrating communication between two ECUs in a system using a smart transceiver is shown;

[0013] Figure 8 An exemplary diagram showing a sequence model of functional safety measures and safety measures is provided;

[0014] Figure 9 An exemplary diagram of an ECU including TransNACK circuitry is shown;

[0015] Figure 10 An exemplary process for sending messages from a source ECU to a destination ECU using the sequence model is shown; and

[0016] Figure 11 An exemplary process is shown whereby the destination ECU receives messages from the source ECU using the sequence model described above. Detailed Implementation

[0017] Detailed embodiments of the invention are disclosed herein as requested; however, it should be understood that the disclosed embodiments are merely illustrative of the invention, which may be embodied in different and alternative forms. The drawings are not necessarily drawn to scale; some features may be enlarged or minimized to show details of specific components. Therefore, the specific structural and functional details disclosed herein should not be construed as limiting, but merely as a representative basis for teaching those skilled in the art to employ the invention in different ways.

[0018] The system may include a first application that executes on a first ECU and uses a first communication stack of the first ECU to access the physical transmission medium. The system may also include a second application that executes on a second ECU, wherein the second application uses a second communication stack of the second ECU to access the physical transmission medium. Functional safety measures and security measures serve different purposes and prevent different types of problems in such a system. Both security measures and security measures require network bandwidth or other resources to implement. This disclosure proposes two models to handle the security and functional safety of data communication between vehicle ECUs, while providing an optimal balance between security, functional safety, and resource overhead.

[0019] It should be noted that many of the examples discussed herein specifically relate to the transportation sector and vehicles. However, it should be noted that the described techniques can be applied to other systems comprising at least two ECUs and a communication medium between said ECUs, wherein the ECUs support both functional safety end-to-end (E2E) communication protection and safety communication protection. For example, the described techniques can also be applied to medical, agricultural, and / or industrial fields.

[0020] Figure 1 An exemplary system 100 is shown, comprising a vehicle 102 implementing functional safety measures and safety procedures. The vehicle 102 may include a vehicle computing system (VCS) 104 configured to communicate via a wide area network 120, for example, using a mobile device 110 or a telematics control unit (TCU) 118-A. The system also includes a remote data server 126 configured to communicate with the vehicle 102 via the wide area network 120. Although... Figure 1 An exemplary system 100 is shown, but the exemplary components shown are not intended to be limiting. In practice, system 100 may have more or fewer components and may use additional or alternative components and / or implementations. It should be noted that the use of the vehicle 102 environment is illustrative, as functional safety measures and safety mechanisms can be used in other types of systems, such as flight control systems in aircraft, or medical devices or industrial machines.

[0021] Vehicle 102 may include various types of automobiles, cross-purpose vehicles (CUVs), sport utility vehicles (SUVs), trucks, recreational vehicles (RVs), boats, aircraft, or other mobile machinery used for transporting people or goods. In many cases, vehicle 102 may be powered by an internal combustion engine. As another possibility, vehicle 102 may be a hybrid electric vehicle (HEV) powered by both an internal combustion engine and one or more electric motors, such as a series hybrid electric vehicle (SHEV), a parallel hybrid electric vehicle (PHEV), or a parallel / series hybrid electric vehicle (PSHEV). Because the type and configuration of vehicle 102 can vary, the capabilities of vehicle 102 can vary accordingly. As some other possibilities, vehicle 102 may have different capabilities regarding passenger capacity, towing capacity and storage capacity.

[0022] VCS 104 can be configured to support driver voice commands and a Bluetooth interface with a device carried by the driver, receive user input via various buttons or other controls, and provide vehicle status information to the driver or other occupants of vehicle 102. An exemplary VCS 104 could be a SYNC system provided by Ford Motor Company in Dearborn, Michigan.

[0023] VCS 104 may also include various types of computing devices to support the execution of the functions of VCS 104 described herein. In the example, VCS 104 may include one or more processors 106 configured to execute computer instructions, and a storage device 108 medium thereon capable of maintaining computer-executable instructions and / or data. A computer-readable storage medium (also referred to as a processor-readable medium or storage device 108) includes any non-transitory (e.g., tangible) medium involved in providing data (e.g., instructions) that can be read by a computer (e.g., by a processor). Typically, processor 106 receives instructions and / or data, such as from storage device 108, into memory and uses the data to execute instructions, thereby performing one or more processes, including one or more processes described herein. Computer-executable instructions can be compiled or interpreted from computer programs created using various programming languages ​​and / or technologies, including but not limited to (alone or in combination): Java, C, C++, C#, Fortran, Pascal, Visual Basic, Python, JavaScript, Perl, PL / SQL, etc.

[0024] VCS 104 can be configured to communicate with a mobile device 110 belonging to a vehicle occupant. The mobile device 110 can be any of various types of portable computing devices, such as a cellular phone, tablet computer, smartwatch, laptop computer, portable music player, or other device capable of communicating with VCS 104. Like VCS 104, the mobile device 110 may include one or more processors configured to execute computer instructions, and storage media thereon capable of maintaining computer-executable instructions and / or data. In many examples, VCS 104 may include a wireless transceiver (e.g., a Bluetooth controller, ZigBee transceiver, Wi-Fi transceiver, etc.) configured to communicate with a compatible wireless transceiver of the mobile device 110. Alternatively or concurrently, VCS 104 may communicate with the mobile device 110 via a wired connection, such as a USB connection between the mobile device 110 and the VCS 104's USB subsystem.

[0025] VCS 104 can also receive input from human-machine interface (HMI) controls 112 configured to provide occupant interaction with vehicle 102. For example, VCS 104 may interface with one or more buttons or other HMI controls 112 configured to invoke functions on VCS 104 (e.g., steering wheel audio buttons, push-button talk buttons, dashboard controls, etc.). VCS 104 can also drive or otherwise communicate with one or more displays 114, which are configured to provide visual output to vehicle occupants, for example, via a video controller. In some cases, display 114 may be a touchscreen also configured to receive user touch input via a video controller, while in other cases, display 114 may simply be a display without touch input capability. In one example, display 114 may be a host unit display included in the center console area of ​​vehicle 102 cabin. In another example, display 114 may be a screen for a gauge set in vehicle 102.

[0026] VCS 104 can also be configured to communicate with other components of vehicle 102 via one or more vehicle-to-vehicle networks 116. As some examples, vehicle-to-vehicle network 116 may include one or more of a vehicle controller area network (CAN), an Ethernet network, or a media-oriented system transport (MOST). Vehicle-to-vehicle network 116 may allow VCS 104 to communicate with other vehicle 102 systems, such as a vehicle modem of TCU 118-A (which may not be present in some configurations), a Global Positioning System (GPS) module 118-B configured to provide current position and heading information of vehicle 102, and various other vehicle ECUs configured to cooperate with VCS 104. As some non-limiting possibilities, the vehicle ECU may include: a powertrain control module (PCM) 118-C configured to provide control of engine operating components (e.g., idle speed control components, fuel delivery components, emission control components, etc.) and monitoring of engine control components (e.g., the status of engine diagnostic codes); a body control module (BCM) 118-D configured to manage various power control functions, such as exterior lighting, interior lighting, keyless entry, remote start, and access point status verification (e.g., the closing status of the hood, doors, and / or trunk of vehicle 102); a radio transceiver module (RCM) 118-E configured to communicate with a key fob or other local vehicle 102 device; and a climate control management (CCM) module 118-F configured to provide control and monitoring of heating and cooling system components (e.g., compressor clutch and blower fan control, temperature sensor information, etc.).

[0027] As some non-limiting examples, WAN 120 may include one or more interconnected communication networks, such as the Internet, cable television distribution networks, satellite link networks, local area networks, wide area networks, and telephone networks. Using an embedded modem of VCS 104 (or a mobile device 110 of a user connected to VCS 104), vehicle 102 may be able to send output data from vehicle 102 to a network destination on WAN 120 and receive data input to vehicle 102 from a network destination on WAN 120.

[0028] TCU 118-A may include a cellular modem or other network transceiver configured to facilitate communication between vehicle 102 and other devices of system 100 via wide area network 120. In one example, VCS 104 may be configured to access the communication features of TCU 118-A by communicating with TCU 118-A via vehicle bus 116. As some examples, vehicle bus 116 may include a controller area network (CAN) bus, an Ethernet bus, or a MOST bus. In other examples, VCS 104 may access wide area network 120 using the communication services of mobile device 110. In one example, VCS 104 may communicate with mobile device 110 via a local area connection (e.g., Bluetooth), and mobile device 110 may then communicate via wide area network 120 using its cellular modem.

[0029] Mobile application 122 may be included on storage device 108 of VCS 104. Mobile application 122 may include instructions that, when executed by the processor of VCS 104, cause VCS 104 to perform operations such as displaying a map depicting vehicles against a background of surrounding roads. Mobile application 122 may use data 124 to maintain location indications of maps such as deserts, mountains, and building outlines on storage device 108 of VCS 104.

[0030] Remote data server 126 can be configured to communicate with vehicle 102 via wide area network 120. In one example, remote data server 126 can send commands to vehicle 102, such as door unlocking requests. In another example, remote data server 126 can receive information from vehicle 102, such as vehicle health reports or diagnostics.

[0031] Figure 2 An exemplary diagram is shown of an ECU 118 configured for communication via a vehicle bus 116. As shown, the ECU 118 includes application software 202 that can execute on the processor of the ECU 118. The application software 202 can access the RAM 204 of the ECU 118, which is also used by the operating system (OS) 206 of the ECU 118. The OS 206 can also access a bus buffer 208, which stores data that will be read by a bus controller 210. The bus controller 210 can communicate with a bus transceiver 212, which transmits data between the ECU 118 and the vehicle bus 116.

[0032] Messages can be generated in the application area by application software 202. This area is developed with high integrity to meet functional safety standards such as ISO 26262 and IEC 61508 for safety-critical systems. This area is considered a safety zone (e.g., high integrity design). As some possibilities, the safety zone or high integrity zone can use functional safety standards depending on the industry, such as automotive (ISO 26262), aerospace (RTCA / DO-178B), medical (IEC 60601), railway (EN 50128), machinery (IEC 6206), nuclear power plants (IEC 60880), process industries (IEC 61511), and general functional safety standards (IEC 61508).

[0033] E2E protection is designed to prevent random hardware or system software and / or hardware failures that may occur in the middleware areas shown in the diagram (e.g., insecure areas). Due to factors such as cost and efficiency, insecure areas may not be able to be developed as application areas to a high level of integrity.

[0034] As discussed in detail herein, the described system should cover a wide range of fault types that may be triggered in unsafe areas, potentially leading to various communication failure modes (listed in Table 1). For example, system software faults may include interrupted data transmission, receiver overflow (e.g., buffer overflow), or transmitter underload (e.g., empty buffer). As another example, random hardware faults may include those caused by electrical overload, degradation, aging, or exposure to external influences such as environmental stress. As yet another example, transient faults may include those caused by external influences such as electromagnetic interference (EMI), electrostatic discharge (ESD), humidity, corrosion, temperature, or mechanical stress / vibration. The described system should address the faults listed in Table 1, as well as similar failure modes detectable through industry-standard E2E protection methods and control fields.

[0035] Table 1

[0036]

[0037]

[0038] Figure 3An exemplary diagram 300 is shown for a message 302 sent by ECU 118. Message 302 can be provided to the vehicle bus 116 by the bus transceiver 212 of ECU 118 for reception by other ECUs 118. As shown, message 302 includes a safety-critical signal 304, an E2E header 306 including an E2E control field 308, a safety-critical signal 310, a safety header 312 including a safety control field 314, and various non-critical signals 316. As some possibilities, the exemplary E2E control field 308 may include a data identifier, a counter, a checksum, and a cyclic redundancy check (CRC). As some possibilities, the exemplary safety control field may include freshness, a counter, and a MAC.

[0039] Freshness values ​​can be instantiated as local timer values, global real-time counter values, secure message counters, or secure trip counters. Freshness values ​​can also be created as combinations of these possibilities, either additionally or alternatively. The MAC can be calculated dynamically. For example, the MAC can be calculated based on a combination of the security key, the signal being transmitted, and the freshness value. Therefore, the MAC may change over time; for example, each transmission of any message 302 may result in a different MAC value. A person can identify from the correct MAC that message 302 came from the correct sender, has not been modified, and is fresh.

[0040] It should be noted that the data elements and their order in message 302 are merely examples, and more, fewer, different, or different orderings of fields may be used. It should also be noted that there may be partial or even complete overlap between security critical signals 310 and 314, but message 302 may still include two headers, one for E2E and one for security.

[0041] E2E protection and security protection methods can follow the following pattern. On the transmitter side, the transmitter can determine which signals in message 302 require E2E protection and security protection, generate E2E control fields 308 and security control fields 314 based on the protected signals, and add E2E control fields 308 and security control fields 314 to the transmitted data. On the receiver side, the receiver can recalculate E2E control fields 308 and security control fields 314 from the received data, compare them with the received content, and take appropriate responses in case of mismatch. As some examples, various methods can be used to generate E2E protection and security protection, such as manual coding, AUTSAR configurable modules, or model-based development. Various communication protocols can also be used, such as CAN, LIN, Ethernet, and other wired and wireless communications. Various ECUs 118 can participate in the communication of message 302, such as the exemplary ECU 118 discussed above, vehicle controls, and mobile devices 110 connected to vehicle 102.

[0042] E2E protection differs from security threat protection in several ways. Regarding the source, E2E threats are non-malicious and arise within the system from system design flaws, random hardware failures, or external interfaces (the insecure areas shown in the diagram). In contrast, security handles malicious attacks from external sources. Regarding the nature, E2E threats can be predicted and modeled (e.g., failure modes caused by EMI failures can be modeled and behavior predicted). In contrast, security threats are unpredictable because hackers can often arise spontaneously around protection mechanisms. Regarding coverage and complexity, typically only a subset of Message 302 will require E2E protection, and E2E protection measures are usually simple and cover a short Hamming distance. In contrast, security covers more data and is complex due to the different nature of threats. Regarding integrity and efficiency, E2E protection is generated using high-integrity software and hardware components according to strict design rules specified in functional safety standards, while security protection is generated using highly efficient SW and HW components due to the complexity of MAC.

[0043] E2E protection is similar to security threat protection in some respects. Regarding failure modes, as examples, they both handle similar failure modes such as message 302 insertion, corruption, loss, and delay. Regarding protection mechanisms, the control fields 308 used in E2E protection (such as counters and CRC) are similar to (but generally simpler than) the security control field 314.

[0044] Figure 4An exemplary diagram 300 illustrates communication between two ECUs 118 of a broadcast network system 100. As shown, security-critical information 304 in message 302 is generated by the transmitter ECU 118 in a high-integrity application area (secure zone). E2E protection is also generated in the secure / high-integrity zone. Message 302, including the E2E protection control field 308, "passes through" the insecure zone. Security protection 314 (e.g., MAC, freshness, counter, etc.) is generated in the insecure / high-integrity zone. Both E2E protection 308 and security protection 314 are added to the original message 302 (payload) and transmitted by the communication transceiver via the vehicle bus 116. The internal protection of the vehicle bus 116 can vary. For example, CAN message 302 is transmitted with a built-in CRC (e.g., added by transceiver 212), but this protection is limited in coverage (e.g., it does not prevent message 302 insertion, delay, etc.) and does not prevent failure modes that occur in the insecure zone. Receiver ECU 118 receives message 302 (with added E2E and security protection). Verify security protection in the receiver's unsafe / efficient middleware area. Verify E2E protection in the receiver's safe / high integrity application area.

[0045] Figure 5 An exemplary diagram 500 illustrates the details of communication between two ECUs 118 of system 100. In diagram 500, the signal lifetime of communication between a first ECU 118 (i.e., ECU1) and a second ECU 118 (i.e., ECU2) is shown. At time point 1 (TP1), application software 202 executed by ECU1 creates a signal. At time point 2 (TP2), the signal is packaged into message 302 at ECU1 and loaded into the ECU1 communication stack. At time point 3 (TP3), message 302 created at TP2 is transmitted by the communication transceiver of ECU1 (included in the communication stack in the diagram) via vehicle bus 116. In this example, vehicle bus 116 may include a physical transmission medium such as CAN, CAN-FD, or Ethernet. At time point 4 (TP4), message 302 transmitted at TP3 is received by ECU2 via the physical transmission medium. At time point 5 (TP5), message 302 received at TP4 is processed by the communication stack of ECU2 to unpack the signal from the received message 302. At time point 6 (TP6), ECU2 processes the received signal through application software 202 executed by ECU2.

[0046] Figure 6 An exemplary diagram 600 illustrates a standalone model of functional safety measures and security measures. This standalone model includes a further set of safety and security measures that can be implemented within the context of the communication illustrated above with respect to diagram 200.

[0047] In the standalone model, E2E protection 308, such as a checksum and a counter, is created during TP1. The checksum and counter are then packaged into the message 302 to be transmitted. In the example, the checksum can be created as the two's complement of the sum of the two's complement of message 302. In another example, the counter can be any incrementing value, for example, based on a variable of the message 302 stream maintained between ECU1 and ECU2 at ECU1. These values ​​can be added to increase security, for example, to prevent electronic processing errors when sending message 302.

[0048] During TP2, for example, security protections 314, such as freshness values ​​and MAC values, are created via the communication stack of ECU1. The freshness value and MAC value are then packaged into message 302, which is to be transmitted. In this example, the freshness value could be a timestamp, for example, a value derived from current time information. Therefore, the freshness value can be used to identify whether message 302 was recently sent or is already old. The MAC value could be the MAC address of the communication stack of ECU1. These values ​​can be added to increase security, for example, to prevent electronic processing errors by ECU1 or during channel transmission, and to mitigate short-term replay threats and signal spoofing from attackers.

[0049] Message 302, which includes an additional checksum, counter, freshness, and MAC value, can be transmitted at TP3 by the communication stack of ECU1 via the vehicle bus 116, and received at TP4 by the communication stack of ECU2.

[0050] During TP5, ECU2's communication stack verifies the freshness and MAC address of the received message 302. In one example, ECU2 can verify that the freshness indicator message 302 was sent less than a predefined threshold time ago. In another example, ECU2 can verify that the MAC address belongs to the expected sender ECU1.

[0051] During TP6, ECU2 verifies the checksum and counter aspects of the received message 302. In one example, ECU2 can confirm that the checksum matches the data of the received message 302. In another example, ECU2 can confirm that for each received message 302, the counter corresponds to the next increment.

[0052] Therefore, when using the independent model, the authenticity, integrity, and freshness of message 302 are ensured over the network. Furthermore, end-to-end functional security protection is implemented. As an advantage of the independent model, security and safety are handled independently, meaning that each verification does not interfere with the others. However, compared to the method shown in Figure 500, the independent model may be relatively less efficient over the network because all checksums, counters, freshness values, and MACs are transmitted over the network.

[0053] By sending only safety protections without E2E protection, the additional load on the communication bus can be reduced. Some methods of doing this could include combining E2E and safety within the ECU 118 itself by generating E2E in the unsafe / efficient region or safety in the safe / high integrity region. However, this approach may be impractical.

[0054] Figure 7 An exemplary diagram 700 illustrates communication between two ECUs 118 of a system 100 using a combination of a smart bus controller 210 and / or a smart transceiver 212. As shown in diagram 700, a mechanism is created in which an additional security zone / high integrity zone is located during message 302 processing before the message 302 is transmitted via the vehicle bus 116. This mechanism has two functions. On the transmitter side, the mechanism can verify that message 302 has not been corrupted en route from the application area to the transceiver. If message 302 is corrupted, the mechanism can take a predefined action according to the system's security policy. If no problem is detected, E2E protection 308 can be removed from message 302, and only the security protection will be transmitted in addition to the payload. On the receiver side, the mechanism can recreate E2E protection 308 from the received message 302 and send message 302 including the recreated data to the application area for verification.

[0055] Note that message 302 may be corrupted during transmission between the two ECUs 118. It is worth noting that safety protection 314 can detect corruption while message 302 is being transmitted. However, safety protection does not provide protection within ECU 118, which is the primary operating area for E2E protection.

[0056] Figure 8 An exemplary diagram 800 illustrates a sequence model of functional safety measures and security measures. The sequence model also includes a set of additional security and safety measures that can be implemented in the context of the communication shown above with respect to diagram 500. However, as structurally shown with respect to diagram 700, in the sequence model, E2E protections 308, such as checksums and counters, are not packaged into the message 302 being sent.

[0057] In the sequence model, similar to what is done in the standalone model, E2E protections 308, such as checksums and counter values, are created during TP1. These values ​​are not included in message 302. At TP2, security protections 314, such as freshness values ​​and MAC values, are created, and similar to the standalone model, these values ​​are included in message 302 to be transmitted. However, also during TP2, the checksum and counter are verified before sending message 302 at TP3. In the example, ECU1 can confirm that the checksum matches the data in the received message 302. In another example, ECU1 can confirm that for each received message 302, the counter corresponds to the next increment.

[0058] Message 302, which includes the freshness and MAC value but excludes the checksum and counter value, can be transmitted at TP3 by the communication stack of ECU1 via the vehicle bus 116 and received at TP4 by the communication stack of ECU2.

[0059] During TP5, the combination of the smart bus controller 210 and / or smart transceiver 212 in the communication stack of ECU2 independently generates the checksum and counter values ​​for the received message 302. These values ​​are regenerated by ECU2 because they were not sent to ECU2 by ECU1. In this example, the checksum can be generated using the same method used by ECU1 to generate the checksum. The counter value can be regenerated as an arbitrarily incrementing value, for example, based on a variable of the message 302 stream maintained between ECU1 and ECU2 at ECU2. Also during TP5, ECU2 verifies the freshness and MAC address of the received message 302, similar to that discussed with respect to the independent model. Additionally, during TP6, ECU2 verifies the regenerated checksum and counter associated with the received message 302 in a manner similar to the independent model.

[0060] Therefore, when using the sequence model, the authenticity, integrity, and freshness of message 302 are ensured over the network. Furthermore, end-to-end functional safety protection is achieved through the creation and verification of the E2E control field 308 at ECU1, the authentication and verification of message 302 for network transmission, and the re-creation and verification of the E2E control field 308 at ECU2. As an advantage of the standalone model, network usage is more efficient than implementing the E2E control field 308, except for the security control field 314. However, due to the dual use of end-to-end checksum and counter creation and verification, the signal end-to-end timing may be prolonged.

[0061] Figure 9An exemplary diagram 900 of an ECU 118 is shown. The ECU 118 includes a TransNACK circuit 902, which is an example of a combination of a smart bus controller 210 and / or a smart transceiver 212. The TransNACK circuit 902 performs the functions described above. Figure 8 Detailed description of its function. As shown in the figure, the TransNACK circuit 902 may be a separate component included in the ECU 118 between the bus controller 210 and the bus transceiver 212. In other examples, the TransNACK circuit 902 may be included in the bus controller 210 and / or the bus transceiver 212, or otherwise included in a component connected to a safety zone of the vehicle bus 116. In operation, the TransNACK circuit 902 may be configured to recognize a message 302 that failed to be transmitted to its destination via the ECU 118.

[0062] TransNACK circuit 902 can be configured to provide information to ECU 118 to allow ECU 118 to better track counter variables recreated by ECU 118. For example, a retry mechanism of the vehicle bus 116 (such as CAN retry) can result in receiving multiple identical messages for a single transmission. Therefore, TransNACK circuit 902 can be used to count the actual message 302 transmitted, rather than counting retries of the transmitted message 302, to better allow ECU 118 to track the correct counter value that will be used to verify and recreate the counter value.

[0063] Figure 10 An exemplary process 1000 is shown that uses a sequence model to send message 302 from source ECU 118 to destination ECU 118. In this example, process 1000 can be executed by ECU 118 of system 100, as described in detail with respect to the diagram above.

[0064] At operation 1002, source ECU 118 receives data to send from source ECU 118 to destination ECU 118 in message 302. In the example, an application executed by source ECU 118 may receive or construct data to send to an application executed by destination ECU 118. At 1004, source ECU 118 generates an end-to-end protection value 308 for message 302. In the example, the end-to-end value may include a counter and a checksum value. At 1006, source ECU 118 generates a security value for message 302. In the example, the security value may include a freshness and a MAC value. These end-to-end and security values ​​can be generated as discussed above with respect to the diagrams above (such as diagrams 600 to 700 and 800).

[0065] At 1008, source ECU 118 determines whether the end-to-end value is valid. For example, source ECU 118 verifies counters and checksum values. This verification can be performed by the transceiver security zone via a component similar to TransNack before the message is transmitted to vehicle bus 116. If the value is valid, control proceeds to operation 1010. If not, control proceeds to operation 1014 to indicate an error condition, such as a failure to transmit message 302, and ECU 118 can take additional measures specified in the security policy, such as retrying to transmit the message again. At 1010, source ECU 118 adds a security protection value 314 to message 302. For example, the added security value could include freshness and MAC values. However, the end-to-end value is not added to message 302. At operation 1012, source ECU 118 sends message 302 to destination ECU 118. In this example, message 302 is sent via vehicle bus 116, addressing to destination ECU 118.

[0066] Figure 11 An exemplary process 1100 is shown in which the destination ECU 118 receives message 302 from the source ECU 118 using a sequence model. In this example, as with process 1000, process 1100 can be executed by the ECU 118 of system 100, as described in detail above.

[0067] At operation 1102, the destination ECU 118 receives message 302 from the source ECU 118. In this example, the destination ECU 118 may receive message 302 sent at operation 1012 of process 1000.

[0068] At 1004, the destination ECU 118 regenerates the end-to-end protection 308 values ​​in the secure transceiver area via a component such as TransNack. These values ​​may include counter and checksum values, and can be regenerated by the destination ECU 118 since the counter and checksum values ​​were not sent to the destination ECU 118 by the source ECU 118. In the example, the checksum can be generated using the same method used by the source ECU 118 to generate the checksum. The counter value can be regenerated as an arbitrarily incrementing value, for example, based on a variable of the message 302 stream maintained at the destination ECU 118. This value can be identified via the TransNACK circuitry 902 to resolve issues related to duplicate message 302 or other message 302 transmissions.

[0069] At 1106, destination ECU 118 determines whether the security protection value 314 is valid. In this example, destination ECU 118 may verify that the freshness indication message 302 was sent less than a predefined threshold time ago. In another example, destination ECU 118 may verify that the MAC address is that of the expected sender source ECU 118. If the security value is determined to be valid, control proceeds to operation 1108. If not, control proceeds to operation 1112 to indicate an error condition regarding the reception of message 302.

[0070] At 1108, the destination ECU 118 determines whether the regenerated end-to-end protection 308 value is valid. This verification can be performed by the high integrity application area (security area) 202. In this example, the destination ECU 118 can verify that the checksum matches the data of the received message 302 and that the information was not corrupted in the insecure areas (e.g., 204, 206, and 208) during its journey from the transceiver security area (e.g., 210, 212) to the application security area (e.g., 202). In another example, the destination ECU 118 can verify that for each received message 302, the counter corresponds to the next increment. If the counter and checksum values ​​are determined to be valid, control proceeds to operation 1110 to process message 302. If not, control proceeds to operation 1112.

[0071] The computing devices described herein, such as VCS 104, mobile device 110, ECU 118, and remote data server 126, generally include computer-executable instructions, which can be executed by one or more computing devices such as those listed above. The computer-executable instructions can be compiled or interpreted from computer programs created using various programming languages ​​and / or technologies, including but not limited to (alone or in combination): Java. TM The languages ​​used include C, C++, C#, Visual Basic, JavaScript, Python, Perl, PL / SQL, etc. Typically, a processor (e.g., a microprocessor) receives instructions from memory, computer-readable media, etc., and executes those instructions to perform one or more procedures, including one or more procedures described herein. These instructions and other data can be stored and transmitted using a variety of computer-readable media.

[0072] Regarding the processes, systems, methods, heuristics, etc., described herein, it should be understood that although the steps of such processes are described as occurring in a specific order, such processes can be practiced by performing the steps in an order other than that described herein. It should also be understood that some steps may be performed simultaneously, other steps may be added, or some steps described herein may be omitted. In other words, the description of processes herein is provided for the purpose of illustrating certain embodiments and should in no way be construed as limiting the claims.

[0073] Therefore, it should be understood that the above description is intended to be illustrative rather than restrictive. Upon reading the above description, many embodiments and applications beyond the examples provided will become apparent. The scope should not be determined by reference to the above description, but rather by reference to the appended claims and the full scope of their equivalents. Future developments are anticipated and intended in the art discussed herein, and the disclosed systems and methods will be incorporated into such future embodiments. In conclusion, it should be understood that changes and variations are possible with this application.

[0074] All terms used in the claims are intended to give their broadest reasonable construction and their general meaning as understood by one of skill in the art described herein, unless expressly indicated otherwise herein. Specifically, unless expressly limited to the contrary by the claims, the use of singular articles such as “a,” “the,” or “the” should be interpreted as one or more of the elements indicated by the statement.

[0075] An abstract of this disclosure is provided to allow the reader to quickly determine the nature of the technical disclosure. It should be understood that the submitted abstract will not be used to interpret or limit the scope or meaning of the claims. Furthermore, as can be seen in the above detailed description, various features are combined in various embodiments for the purpose of making the disclosure fluent. This approach of the disclosure should not be construed as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as reflected in the appended claims, the inventive subject matter lies in fewer features than all the features of a single disclosed embodiment. Therefore, the following claims are incorporated herein by reference, wherein each claim is itself a separately claimed subject matter.

[0076] While exemplary embodiments have been described above, it is not intended to describe all possible forms of the invention for these embodiments. Rather, the terminology used herein is descriptive rather than restrictive, and it should be understood that various changes may be made without departing from the spirit and scope of the invention. Furthermore, features of various embodiments may be combined to form other embodiments of the invention.

[0077] According to the present invention, a system is provided having a first electronic control unit (ECU) that communicates with a second ECU via a vehicle bus, wherein the first ECU is configured to: generate a functional safety value and a safety protection value for a message, verify the safety protection value of the message, and send the message including the safety protection value but excluding the functional safety value to the second ECU.

[0078] According to an embodiment, the second ECU is further configured to: regenerate a security protection value in response to receiving a message, and verify the regenerated security protection value of the message.

[0079] According to an embodiment, the security protection value includes a freshness value, the first ECU is further configured to generate the freshness value, and the second ECU is further configured to use the freshness value to verify that the message was sent before a predefined threshold time.

[0080] According to an embodiment, the functional safety value includes a counter value, and the first ECU is also configured to generate the counter value as an arbitrary increment based on the variable of the message flow from the first ECU to the second ECU.

[0081] According to an embodiment, the second ECU includes a TransNACK circuit configured to count the actual messages sent or received in the message stream to allow the creation of a counter value.

[0082] According to an embodiment, the first ECU is further configured to execute a first application programmed to generate messages, and the second ECU is further configured to execute a second application programmed to receive messages.

[0083] According to an embodiment, the second ECU is further configured to: generate a functional safety value and a safety protection value for a second message in response to the message, verify the functional safety value of the second message, and send a second message including the safety protection value of the second message but not the functional safety value of the second message to the first ECU.

[0084] According to the present invention, a method is provided comprising: generating a functional safety value of a message by a first electronic control unit (ECU); verifying the functional safety value by the first ECU; sending the message, which includes a safety protection value but does not include the functional safety value, to a second ECU; regenerating the functional safety value by the second ECU; and verifying the regenerated functional safety value by the second ECU.

[0085] According to an embodiment, the security protection value includes a Message Authentication Code (MAC) value.

[0086] According to an embodiment, the first ECU is connected to the second ECU via a vehicle bus.

[0087] According to an embodiment, the invention is further characterized in that: a freshness value is generated by a first ECU; and the freshness value is used by a second ECU to verify that the message was sent before a time less than a predefined threshold time.

[0088] According to an embodiment, the invention is further characterized in that: a first application programmed to generate messages is executed by a first ECU; and a second application programmed to receive messages is executed by a second ECU.

[0089] According to an embodiment, the invention is further characterized by: the second ECU generating a functional safety value for the second message; the second ECU verifying the functional safety value for the second message; sending a message including the safety protection value of the second message but not the functional safety value of the second message to the first ECU; the first ECU regenerating the functional safety value for the second message; and the first ECU verifying the functional safety value for the second message.

[0090] According to an embodiment, the invention is further characterized by using a TransNACK circuit to verify the functional safety value and remove the functional safety value from the message in the first ECU, and regenerating the functional safety value protection in the second ECU.

[0091] According to the present invention, a non-transitory computer-readable medium includes instructions that, when executed by a processor of a first ECU communicating with a second electronic control unit (ECU) via a vehicle bus, cause the first ECU to: generate a functional safety protection control field including a counter and a checksum, and a security protection control field including a message freshness value and a message authentication code (MAC) value; verify the functional safety protection control field of the message; and send a message including the security protection control field but not the functional safety control field to the second ECU.

[0092] According to an embodiment, the invention is further characterized by instructing a first ECU to generate a freshness value, wherein a second ECU uses the freshness value to verify that the message was sent before a time less than a predefined threshold time.

[0093] According to an embodiment, the invention is further characterized by instructing the first ECU to generate a counter value as an arbitrary increment based on the variable of the message flow from the first ECU to the second ECU.

[0094] According to an embodiment, the MAC value indicates the MAC of the first ECU.

[0095] According to an embodiment, the invention is further characterized in that the first ECU executes instructions programmed to generate a first application, wherein the second ECU executes instructions programmed to receive a second application.

[0096] According to an embodiment, the invention is further characterized in that the first ECU uses the TransNACK circuit to verify the functional safety control field, remove the functional safety control field from the message in the first ECU, and regenerate the instruction for the functional safety control field in the second ECU.

Claims

1. A system for protecting communication between electronic control units, comprising: The first electronic control unit (ECU) communicates with the second ECU via the vehicle bus. The first ECU is configured as follows: The system generates functional security values ​​and security protection values ​​for the message. The functional security values ​​include a counter value and a checksum value. The security protection values ​​include a freshness value and a message authentication code value. The functional safety value of the message is verified using a counter maintained by a TransNACK circuit, which updates the counter by counting messages sent by the first ECU but not by counting retries of sent messages. The message, which includes the safety protection value but not the functional safety value, is sent to the second ECU, causing the second ECU to regenerate the functional safety value.

2. The system according to claim 1, wherein, The second ECU is also configured to: In response to receiving the message, the functional safety value is regenerated, and Verify the regenerated functional security value of the message.

3. The system according to claim 1, wherein, The first ECU is also configured to generate the freshness value, and the second ECU is also configured to use the freshness value to verify that the message was sent before a predefined threshold time.

4. The system according to claim 1, wherein, Furthermore, the first ECU is configured to generate the counter value as an arbitrary increment based on variables in the message flow from the first ECU to the second ECU.

5. The system according to claim 4, wherein, The second ECU includes another TransNACK circuit configured to count the actual messages sent or received in the message stream to allow the counter value to be recreated.

6. The system according to claim 1, wherein, The first ECU is further configured to execute a first application programmed to generate the message, and the second ECU is further configured to execute a second application programmed to receive the message.

7. The system according to claim 1, wherein, The second ECU is also configured to: In response to the message, a second message is generated with a functional security value and a security protection value. Verify the functional security value of the second message, and The second message, which includes the security protection value of the second message but does not include the functional safety value of the second message, is sent to the first ECU.

8. A method for protecting communication between electronic control units, comprising: The functional safety value of the message generated by the first electronic control unit (ECU) includes a counter value and a checksum value. The first ECU uses a counter maintained by a TransNACK circuit to verify the functional safety value, which updates the counter by counting the messages sent by the first ECU without counting retries of the sent messages. Remove the functional safety value from the message in the first ECU; The message, which includes a safety protection value but not the functional safety value, is sent to the second ECU. The safety protection value includes a freshness value and a message authentication code value. The functional safety value is regenerated by the second ECU; as well as The regenerated functional safety value is verified by the second ECU.

9. The method according to claim 8, wherein, The first ECU is connected to the second ECU via a vehicle bus.

10. The method of claim 8, further comprising: The freshness value is generated by the first ECU; as well as The second ECU uses the freshness value to verify that the message was sent less than a predefined threshold time ago.

11. The method of claim 8, further comprising: The first application, programmed to generate the message, is executed by the first ECU. as well as The second application, programmed to receive the message, is executed by the second ECU.

12. The method according to claim 8, further comprising: The functional safety value of the second message is generated by the second ECU; The second ECU verifies the functional safety value of the second message; The message that includes the security protection value of the second message but does not include the functional security value of the second message is sent to the first ECU; The first ECU regenerates the functional safety value of the second message; as well as The first ECU verifies the functional safety value of the second message.

13. A non-transitory computer-readable medium comprising instructions that, when executed by a processor of a first ECU communicating with a second electronic control unit (ECU) via a vehicle bus, cause the first ECU to perform the following operations: The message generation includes a functional security protection control field and a security protection control field. The functional security protection control field includes a counter value and a checksum value. The security protection control field includes a freshness value and a message authentication code value. The functional security protection control field of the message is verified using a counter maintained by a TransNACK circuit, which updates the counter by counting messages sent by the first ECU without counting retries of the sent messages. Remove the functional safety protection control field from the message in the first ECU; The message, which includes the safety protection control field but not the functional safety protection control field, is sent to the second ECU, causing the second ECU to regenerate the functional safety protection control field.

14. The non-transitory computer-readable medium of claim 13, further comprising instructions for causing the first ECU to generate the freshness value, wherein, The second ECU uses the freshness value to verify that the message was sent less than a predefined threshold time ago.

15. The non-transitory computer-readable medium of claim 13, further comprising an instruction that causes the first ECU to generate the counter value as an arbitrary increment based on a variable of the message flow from the first ECU to the second ECU.

16. The non-transitory computer-readable medium of claim 13, further comprising instructions for causing the first ECU to execute instructions programmed to generate the message by a first application, wherein, The second ECU executes a second application programmed to receive the message.

Images