Clock Control for Increasing the Robustness of a Serial Bus Interface

Abstract

Clock control for increasing the robustness of a serial bus interface. An electronic control unit (ECU) includes a processor, a controller area network (CAN) controller, clock gating logic, and security gating logic. The CAN controller has a state and is configured to: receive data and control signals, as well as a clock signal, from the processor; encapsulate the data to create a CAN protocol frame stored in at least one transmit buffer; and shift the CAN protocol frame to a CAN transceiver, which is configured to transmit the CAN protocol frame to a CAN bus. The clock gating logic can be configured to selectively disable the clock signal to the CAN controller based on a control signal from the processor. The security gating logic is configured to prohibit the disabling of the clock signal in response to the state of the CAN controller being active.

Description

Technical Field

[0001] The present invention generally relates to systems and methods for increasing the robustness of a message-based protocol serial bus interface via enhanced gating and idle clock detection. Background Art

[0002] Modern vehicles include multiple electronic control units (ECUs). Most of these ECUs communicate via a communication bus that uses a communication protocol (e.g., Controller Area Network (CAN) protocol). The topology of multiple ECUs communicating via a communication bus creates an in-vehicle network that controls many vehicle systems and has led to many advancements in vehicle operation. However, along with the added functionality, these in-vehicle networks have become a prime target for automotive cyberattacks. Summary of the Invention

[0003] An electronic control unit (ECU) includes a processor, a Controller Area Network (CAN) controller, clock gating logic, and security gating logic. The CAN controller has a state and is configured to: receive data and control signals from the processor, and a clock signal; encapsulate the data to create a CAN protocol frame stored in at least one transmit buffer; and shift the CAN protocol frame to a CAN transceiver, the CAN transceiver being configured to transmit the CAN protocol frame to a CAN bus. The clock gating logic may be configured to selectively disable the clock signal to the CAN controller based on a control signal from the processor. The security gating logic is configured to prohibit disabling the clock signal in response to the state of the CAN controller being active.

[0004] An electronic control unit (ECU) includes a processor, a controller, clock gating logic, and security gating logic. The controller may be configured to: receive data and control signals from the processor; encapsulate the data to create a protocol frame stored in at least one transmit buffer; and serially shift the protocol frame to a transceiver via a shift buffer, the transceiver being configured to receive serial data from the controller and transmit a signal on a bus. The clock gating logic may be configured to selectively disable the clock to the controller based on a signal from the processor. The security gating logic is configured to prohibit disabling the clock in response to the state of the controller being active.

[0005] An electronic control unit (ECU) includes a processor, a controller, clock gating logic, security gating logic, and reset logic. The controller can be configured to receive data and control signals from the processor; encapsulate the data to create protocol frames stored in at least one transmission buffer; and serially shift the protocol frames to a transceiver via a shift buffer, where the transceiver is configured to receive serial data from the controller and transmit the protocol frames on a bus. The clock gating logic can be configured to selectively disable the clock to the controller based on a signal from the processor. The security gating logic can be configured to prohibit disabling the clock in response to a controller state indicating an active transmission of a protocol frame. The reset logic can be configured to reset the at least one transmission buffer when the signal transitions from active to inactive. Description of the Drawings

[0006] Figure 1 is a block diagram of a Controller Area Network (CAN) stack in an electronic control unit (ECU).

[0007] Figure 2 is a block diagram of a CAN stack in an ECU with coupled power and clock.

[0008] Figure 3 is a flowchart of an attack on a CAN controller via arbitrary bit insertion.

[0009] Figure 4 is a flowchart of a single dominant bit inserted by a CAN controller for an arbitrary duration.

[0010] Figure 5 is a block diagram of clock gating for a CAN controller.

[0011] Figure 6 is a block diagram of clock gating for a CAN controller via status and enable.

[0012] Figure 7 is a block diagram of clock, data bus, and control bus gating for a CAN controller via status and enable.

[0013] Figure 8 is a block diagram of the transmission buffer status based on the transmission buffer value.

[0014] Figure 9 is a block diagram of a reset circuit for resetting the transmission buffer via an asynchronous reset signal.

[0015] Figure 10 is a block diagram of a reset circuit for resetting the transmission buffer via a synchronous reset signal.

[0016] Figure 11A is a block diagram of a detection circuit for detecting a persistent high clock signal.

[0017] Figure 11B It is a block diagram of a detection circuit for detecting a continuous low clock signal.

[0018] Figure 12 It is a flowchart of a peripheral device status check function.

[0019] Figure 13 It is a flowchart of a peripheral device status check function via a secure co-processor.

[0020] Figure 14 It is a flowchart of a peripheral device status check function via a transition to a secure operating mode.

[0021] Figure 15 It is a flowchart of a peripheral device status check function via compiler instructions.

[0022] Figure 16 It is a block diagram of a communication bus including a supervision node, an attacker node, and a target node. Detailed implementation

[0023] As required, detailed embodiments of the present invention are disclosed herein; however, it should be understood that the disclosed embodiments are merely examples of the present invention that can be embodied in various and alternative forms. The figures are not necessarily to scale; some features may be enlarged or minimized to show details of particular components. Accordingly, 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 present invention in different ways.

[0024] The term "substantially" may be used herein to describe the disclosed or claimed embodiments. The term "substantially" may modify a value or relative characteristic disclosed or claimed in the present disclosure. In such instances, "substantially" may indicate that the value or relative characteristic it modifies is within 0%, 0.1%, 0.5%, 1%, 2%, 3%, 4%, 5% or 10% of the value or relative characteristic.

[0025] Security mechanisms for preventing remote software-based attacks on nodes connected to a Controller Area Network (CAN) bus assume adversarial actions are limited to messages that exploit the physical layer specifications of ISO-11898 / 1, ISO-11898 / 2, ISO-11898 / 3, etc., which are attached to the framing and timing of control messages. However, such an assumption is no longer sufficient for ECUs that utilize the CAN bus. This disclosure illustrates software methods that can be used to transmit messages that do not conform to CAN specifications by abusing CAN controller functionality. Also disclosed are novel methods for using a variety of software- and hardware-based control structures to efficiently protect CAN controllers from such attacks. These concepts are illustrated via a specific CAN architecture, however these concepts are also applicable to other CAN architectures, such as Single-Wire CAN (SW-CAN or SWC), Flexible Data Rate CAN (FD-CAN or CAN FD), J1939, and ISO11783. Additionally, these concepts can be applied to other serial bus architectures, such as Ethernet (IEEE802.11 and its variants), Local Interconnect Network (LIN), Flexray (ISO 17458-1 to 17458-5).

[0026] The CAN bus is a central communication network that is used in many systems, including automotive systems, aerospace systems, consumer systems, and industrial systems. Adding remote interfaces to some of the nodes on the bus creates vulnerabilities and exposes these systems to remote attacks. These vulnerabilities have become operational and security concerns. Therefore, as technology advances and vehicle operation autonomy increases, improving the security of the CAN bus has become an important topic.

[0027] Due to the original design principles for CAN and computing capabilities of typical nodes on the network, the difficulty of integrating security into the network has increased significantly. Techniques for solving this problem include the use of novel key negotiation mechanisms, lightweight authentication schemes, and dedicated intrusion detection systems (IDS). Some of these mechanisms assume adversarial actions are limited to compromising the software on the node, thus providing the attacker with the ability to inject any CAN-compliant message. Such an assumption allows for the optimization of the design of security mechanisms.

[0028] However, modern integrated CAN interfaces may allow an adversary to maliciously inject messages that do not conform to the CAN protocol by exploiting existing software interfaces. This includes arbitrary bit injection or partial (erroneous) message insertion. Existing defense mechanisms are ineffective against this new class of adversaries. Here, systems and methods are disclosed that can be used to prevent the misuse of CAN controllers, thereby limiting adversary control.

[0029] Turning to software-based bit insertion, Figure 1 illustrates the layer structure of a traditional node on the CAN bus. Figure 1It is a block diagram of a Controller Area Network (CAN) stack 100 in an electronic control unit (ECU). The CAN stack 100 includes a processor 102, such as a microcontroller, an embedded processor, a processor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a similar device. The processor 102 communicates with a CAN controller 104 by sending and receiving data such as message IDs and data payloads. A CAN transceiver 106 is an interface between the CAN protocol controller 104 and the physical lines of the CAN bus. The CAN bus lines are typically 2-wire (e.g., twisted pair), but can be implemented as single-wire CAN (e.g., GM-LAN) or 4-wire (including a common ground). The interface between the CAN controller 104 and the CAN transceiver 106 can be via 2-wire dedicated TX-RX, RX-TX, where the transmit (TX) on the CAN controller 104 is coupled to the receive (RX) of the CAN transceiver 106, and the RX on the CAN controller 104 is coupled to the TX of the CAN transceiver 106.

[0030] As in traditional layered designs, the traditional and common assumption is that interactions between layers occur only at the message-sending interfaces. In a traditional CAN stack, the CAN controller monitors the bus for transmitted packets and ensures that all transmitted messages conform to the CAN protocol.

[0031] The CAN controller receives a data payload and a message ID from the application and sends a CAN-compliant message frame to the CAN transceiver, which transmits an analog signal on the bus (i.e., the physical line). The controller ensures proper contention resolution operations, such as backing off if arbitration is lost between two simultaneous transmitters, thus ensuring proper transmission of error frames, message ID filtering, and maintenance of the inter-frame space (IFS).

[0032] CAN controller logic is typically implemented in hardware. Thus, it is assumed that an adversary limited to software manipulation cannot modify the behavior of the CAN controller. Thus, the messages transmitted on the bus are assumed to be CAN-compliant.

[0033] In some modern ECUs, the CAN controller and the processor are part of the same physical package, which can be implemented as a multi-chip module (MCM) or by monolithically integrating CAN controller peripherals with the processor, thus exposing new interfaces to the MCU, including a clock control interface and a power control interface. As Figure 2The new interface shown in the figure is generally invisible to the application and is used by the low-level device driver to optimize chip power consumption and for use during debug operations. However, malware can exploit such an interface to affect the structure of messages transmitted on the bus. Generally, the CAN system clock is derived from the MCU system clock or from an external oscillator. This provides a possible CAN system clock frequency which is typically limited by a prescaler to an integer fraction of the MCU system clock or oscillator. The CAN system clock is selected such that the desired CAN bus nominal bit time (NBT) is, for example, an integer number of time quanta (CAN system clock cycles) from 8 to 25. For example, consider a bit rate of 125 k bits per second, bus length = 50 m, bus propagation delay = 5 x 10-9 s m-1, propagation delay of the physical interface (transmitter plus receiver) at 85°C of 150 ns, and MCU oscillator frequency = 8 MHz. A prescaler value of 4 gives a CAN system clock of 2 MHz and a time quantum of 500 ns. This will give 8000 / 500 = 16 time quanta per bit.

[0034] Figure 2 FIG. 4 is a block diagram of a CAN stack 200 in an ECU having a coupled power control interface and clock. The CAN stack 200 includes a processor 202 such as a microcontroller, an embedded processor, a processor, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or the like. The processor 202 communicates with a CAN controller 204 by sending and receiving data such as message IDs and data payloads and via an interface including a clock interface and a power control interface. A CAN transceiver 206 is an interface between the CAN protocol controller 204 and the physical line of the CAN bus.

[0035] Figure 3It is a flowchart of the precursor 300 of an attack on the CAN controller via bit stuffing. In step 302, the controller (e.g., controller 102, 202) enables the clock to the CAN controller (e.g., controller 104, 204). In step 304, the controller (e.g., controller 102, 202) configures the CAN controller (e.g., controller 104, 204), such as baud rate, message filter, and protocol (e.g., GM-LAN, FNOS, etc.). In step 306, the controller (e.g., controller 102, 202) waits for the inter-frame space (IFS) detection received from the CAN controller (e.g., controller 104, 204) (e.g., the recessive bit sequence after the transmission of the end of frame (EOF)). In step 308, the controller (e.g., controller 102, 202) sends a packet to the buffer of the CAN controller (e.g., controller 104, 204) (e.g., ID 0x00 and payload 0101010). Since the ID of 0x00 are all dominant bits, this ID will have the highest priority to access the bus. The ID 0x00 can be 11 bits or 29 bits as part of the arbitration field (ARB) of the CAN message. In step 310, the controller (e.g., controller 102, 202) waits for the arbitration to complete via the arbitration (ARB) field and the data length code (DLC) in the control (CTRL) field indicating the transmission from the CAN controller (e.g., controller 104, 204). In step 312, the controller (e.g., controller 102, 202) disables the clock to the CAN controller (e.g., controller 104, 204). In step 314, the controller (e.g., controller 102, 202) attacks the CAN bus via malicious operations on other modules on the CAN bus by the influence on the CAN bus through the CAN controller (e.g., controller 104, 204).

[0036] Figure 4Flowchart of attack 400 with a single dominant bit inserted by the CAN controller for any duration. In step 402, the controller (e.g., controller 102, 202) starts an attack on the CAN bus via a message sent to the CAN controller (e.g., controller 104, 204). In step 404, the controller (e.g., controller 102, 202) waits for the target message to be sent to the CAN controller (e.g., controller 104, 204). Here, the end of the waiting period can be triggered by an external signal or a start of frame (SOF), which is a single dominant bit before at least 11 recessive bits. In step 406, the controller (e.g., controller 102, 202) enables the clock to the CAN controller using the dominant bit transmitted by the CAN controller (e.g., controller 104, 204). In step 408, the controller (e.g., controller 102, 202) disables the clock to the CAN controller (e.g., controller 104, 204) while recognizing the dominant bit on the CAN bus. In step 410, the controller (e.g., controller 102, 202) enables the clock to the CAN controller while transitioning the CAN bus to the recessive state output by the CAN controller (e.g., controller 104, 204). In step 412, the controller (e.g., controller 102, 202) disables the clock to the CAN controller (e.g., controller 104, 204). In step 414, the controller (e.g., controller 102, 202) branches to another attack on the CAN bus or other messages on the CAN bus via the CAN controller (e.g., controller 104, 204).

[0037] In Figure 3 and Figure 4 illustrated is a general method of transmitting a dominant bit (0 bit) of any length on the CAN bus using the new interface. The CLKOFF / CLKON operations denote actions of disabling and enabling the peripheral clock to the CAN controller (clock gating). The implementation details of this operation vary depending on the specific MCU / ECU. For example, the method of using Arduino Due is to utilize the low-level commands available in the software development kit (SDK) (e.g., pmc_disable_periph_clk). Similarly, for different MCUs, the methods for low-level timing measurements for synchronization actions are different.

[0038] The attack utilizes a message with ID 0x00 and an 8-byte payload with alternating zeros and ones (0101···01). This exemplary attack consists of two different phases. In the first phase, a high-priority message ID is transmitted, causing the CAN controller to enter a state for payload transmission. After waiting for the transmission of the return-to-ready (RTR) bit, the CLKOFF command is used to disable the clock, thereby freezing the state of the CAN controller (e.g., controller 104, 204). This readies the controller (e.g., controller 102, 202) for message transmission. After the identification of the target message, the second attack phase begins. This consists of transmitting the first dominant bit of the payload using the CLKON command. Then, the CLKOFF command is used to freeze the controller in the dominant state. Once the dominant state has been maintained for the desired duration, the controller transitions to the recessive state via consecutive CLKON and CLKOFF signals.

[0039] This mechanism allows for the transmission of a single dominant bit of arbitrary duration at a time chosen by the attacker. The controlled suspension and release of the CAN controller state machine ensure that it is always ready to transmit the attack bit.

[0040] This disclosure illustrates new methods for protecting an ECU (e.g., 100, 200) / CAN controller / Ethernet controller (e.g., controller 104, 204) from being used to transmit non-compliant messages. Regarding the CAN standard, all messages are generally referred to as frames, which include data frames, remote frames, error frames, and overload frames. The information sent to the CAN bus must conform to a defined frame format of different but limited lengths. Non-compliant CAN frames include those that do not meet the specifications documented in the CAN standard ISO11898 published by the International Organization for Standardization (ISO). The advantages of these systems and methods include:

[0041] First, methods for protecting existing CAN systems against a new class of adversaries, which are previously unknown and not protected against.

[0042] Second, the application of the methods at different layers (e.g., hardware, application software, firmware, or built into the compiler), thereby providing system designers with multiple options based on a specific architecture. The hardware methods require minimal circuit redesign and overhead. Additionally, the methods provide flexibility such that they can be implemented by the owner of the CAN controller or the overall system integrator.

[0043] Third, these methods are applicable to a variety of systems that utilize CAN networks, such as automotive, aerospace systems, industrial control systems, building control technologies. Additionally, the disclosed methods can be applied to general systems in which clock control can be utilized to drive a peripheral device into an undesired state.

[0044] The attacks disclosed herein exploit the ability of an MCU (e.g., 102, 202) to perform CLKON / CLKOFF operations from a conventional privileged software interface. Additionally, it relies on the assumption that when the clock is disabled, the CAN controller maintains its state (frozen state) without disabling the power. Thus, several countermeasures can be designed to prevent one or both of these conditions in software. In the present disclosure, several countermeasures are illustrated, including preventing clock disabling, resetting in response to clock disabling, trusted control of peripheral clocks, and cutting off the attacker.

[0045] Preventing clock disabling is a key aspect of preventing attacks on the CAN controller, to prohibit the ability to arbitrarily disable the clock and thereby pause the state of the CAN controller in the middle of a transmission. Disabling the clock enables an attacker to potentially transmit partial and selective message bits. Preventing the clock from being disabled at any time is a technique for preventing arbitrary control.

[0046] Based on the implementation of clock gating logic, several designs are possible for controlling the clock disabling feature. Figure 5 An example of a conventional clock gating mechanism using an active high enable signal is illustrated. Figure 5 is a block diagram of an ECU 500 having clock gating for a CAN controller. The processor 502 communicates with the CAN controller 504 via a control and data bus. Additionally, the processor 502 includes input / output (I / O) pins that can be used to gate the clock via logic 506 (such as an AND gate). The I / O pins perform a CAN enable function for gating the clock. Figure 6 is a block diagram of clock gating for a CAN controller via status and enable.

[0047] Figure 6 is a block diagram of an ECU 600 having a data bus and a control bus and a gated clock for a CAN controller via status and enable. The processor 602 communicates with the CAN controller 604 via the data bus and the control bus, and the clock gating logic 606 is further defined by additional logic 608 (such as a signal indicating the CAN controller status from the CAN controller 604). Figure 6 The system in uses an additional indication line indicating the CAN controller status. Such a status can be a combination of different signals indicating a busy state within the CAN controller. Figure 8 An example of such a mechanism is presented, where the content of the transmit buffer is used to prevent clock gating. For example, the controller can only be disabled when all outstanding messages have been transmitted.

[0048] Figure 8FIG. 800 is a block diagram of a CAN controller 802 having a transmit buffer state based on the value(s) of transmit buffer(s) 806. The CAN controller has a shift register 804 configured to convert data from the transmit buffer(s) 806 into a serial data stream to be transmitted via CAN Tx. The transmit buffer(s) 806 also includes logic 808 to generate a controller status output based on the value or state of the transmit buffer(s) 806.

[0049] It should be noted that such additional signals can prevent the CAN controller from transitioning to a low power mode by continuously adding data to the transmit buffer. This could be exploited by an adversary or cause a denial of service (DoS) attack by an adversary. However, this can be prevented by disabling additional messages from being sent to the controller queue after the clock disable signal has been triggered. Figure 7 An example of such a system is presented where if the clock signal to the controller is disabled, the entire interface between the MCU and the controller is disabled. Depending on the specific implementation, only a subset of the interface signals responsible for initiating new activities may be disabled. Figure 7 FIG. 700 is a block diagram of an ECU 700 having clock, data bus, and control bus gating for the CAN controller via status and enable. The processor 702 communicates with the CAN controller 704 via a gated data bus and a gated control bus, where the gating mechanism is controlled by a clock enable signal. The clock gating logic 706 is further defined by additional logic 708, such as a signal from the CAN controller 704 indicating the CAN controller status.

[0050] A reset for clock disable is another circuit and method for protecting CAN communication integrity. This is based on the enabling factor of the attack being the persistence of the CAN controller state after the clock is disabled. Therefore, an alternative mitigation strategy could be to ensure that the controller is reset to a safe or initialization state if the clock is disabled for a sufficiently long duration. Depending on the CAN controller architecture, several designs are feasible to ensure the reset of the controller state.

[0051] In a simple solution, a reset system is designed using a signal to disable the clock. Such a system is useful in scenarios where an additional port is available via the controller block to accommodate the clock disable signal. Based on the controller architecture and the reset mechanism supported by the timing logic elements, the system can generate a synchronous or asynchronous reset signal.

[0052] To prevent the simplest attacks, it is required that the signal be used to at least reset the transmit buffer. It should be noted that the values of the configuration registers (such as bus speed, receive filter, sampling point) do not pose a security threat and do not need to be reset. This will significantly reduce the CAN setup latency after the clock is re-enabled.

[0053] Figure 9 is a block diagram of a reset circuit for resetting the transmit buffer via an asynchronous reset signal. The CAN controller has a shift register 904, which is configured to convert data from one or more transmit buffers 906 into a serial data stream to be transmitted via CAN Tx. The one or more transmit buffers 906 also include logic 908 to generate a reset of the one or more transmit buffers 906 based on a clock enable input. The logic 908 may include a delay buffer.

[0054] Figure 10 is a block diagram of a reset circuit for resetting the transmit buffer via a synchronous reset signal. The CAN controller has a shift register 1004, which is configured to convert data from one or more transmit buffers 1006 into a serial data stream to be transmitted via CAN Tx. Logic 1008 is used to generate a synchronous reset signal. The logic 1008 may include a D flip-flop with a delay buffer as shown, such that the reset of the transmit buffer is synchronized with the clock.

[0055] Figure 9 illustrates a simple scenario where a clock enable signal is used to directly and asynchronously reset the transmit buffer. Figure 10 illustrates an alternative method for synchronously resetting timing elements. A combination of a D flip-flop triggered by the falling clock edge and a sufficiently large delay buffer on the input is used to ensure that once the clock signal is disabled, the transmit buffer is reset. To ensure proper operation, the delay of the input buffer (d buf ) should be greater than the clock skew of the controller (t skew ). This ensures that the propagation of the enable signal is sufficiently delayed to reset the controller state.

[0056] In architectures where additional ports are not available, the reset generation logic must be inside the controller block. Therefore, the clock signal must be checked for the idle state and used to reset the controller state.

[0057] Such a system requires the following components:

[0058] A clock high-hold detection circuit, which consists of a clock signal and provides an output indicating clock hold if the signal is constant for a period greater than twice the maximum clock period. In other embodiments, the clock hold detection circuit can be 1.5, 2, 3, 4, 5, 10, 20 times the maximum clock period or other appropriate period-based times.

[0059] A clock low-hold detection circuit, which consists of a clock signal and provides an output indicating clock hold if the signal is constant for a period greater than twice the maximum clock period.

[0060] A reset generation mechanism that takes the output of the clock hold detection and outputs a reset signal for a controller element.

[0061] Figure 11A is a block diagram of a CAN control system 1100 having a CAN controller 1102. The CAN controller 1102 has a detection circuit 1110 for detecting a persistent high clock signal. The detection circuit 1110 has a reset circuit 1108 configured to reset the CAN controller 1102 and the transmit buffer(s) 1106. The CAN controller 1102 has a shift register 1104 configured to convert data from the transmit buffer(s) 1106 into a serial data stream to be transmitted via CAN Tx. The CAN controller 1102 also includes persistent clock detection logic 1110 and a reset circuit 1108 to generate a reset for the transmit buffer(s) 1106. The persistent clock detection logic 1110 is configured to detect a persistent high clock signal. Figure 11B An alternative embodiment is illustrated in which is a block diagram of a detection system 1150 having a detection circuit 1152 for detecting a persistent low clock signal.

[0062] Figure 12It is the flowchart of the peripheral device status check function 1200. In step 1202, the controller (e.g., controller 102, 202) checks the status of the peripheral modules (e.g., CAN controller, Ethernet controller, etc.), and it restores the peripheral device to the operating mode (the restoration of the peripheral device includes resetting the transmit buffer to zero, re-initializing the peripheral device, re-executing the peripheral device initialization, etc.). Step 1202 is the start of this function, and this function is called if someone attempts to disable the clock during partial transmission. In step 1204, the controller (e.g., controller 102, 202) checks whether an attempt to disable the clock occurred during partial transmission. If so, the controller will reset the controller data in step 1206, reset the transmit buffer in step 1208, or both. Resetting the controller data in step 1206 includes re-initializing the peripheral device, re-executing the peripheral device initialization, or resetting via the pin or register toggling module. Resetting the transmit buffer in step 1208 includes writing all zeros to the transmit buffer. The controller will proceed to step 1210, where the controller will recognize the clock disable clock signal. If the transmit buffer is empty in step 1204, the controller will jump to step 1210.

[0063] Figure 13 It is the flowchart 1300 of the peripheral device status check function via the secure coprocessor. In step 1302, the controller (e.g., controller 102, 202) proceeds to step 1304 if a clock disable instruction is issued while the controller is in the user-level operating mode. In step 1304, the controller transitions to operation via the secure coprocessor (e.g., secure coprocessor, hardware security module, trust zone (in selected ARM processors), Software Guard Extensions (SGX) (in selected Intel processors), Secure Encrypted Virtualization Technology (in selected AMD processors), Trusted Platform Module), or more generally through a Trusted Execution Environment (TEE), which can be bootstrapped by a secure processor or coprocessor, but it can also be instantiated via a combination of software and hardware. The TEE should run in an isolated environment where operations on data, code, or a combination of both run securely (where securely refers to the integrity of the data, but may also refer to the confidentiality of the data). In the case where the TEE is instantiated via a combination of software and hardware, the software needs to be protected from tampering / modification by other means (e.g., by storing it in read-only memory). In step 1306, the secure coprocessor performs such as Figure 12The peripheral device status check function illustrated therein. For example, the secure coprocessor checks whether an attempt to disable the clock occurred during a partial transfer. If so, the secure coprocessor will reset the controller data as in step 1206, reset the transfer buffer as in step 1208, or both. Then, the secure coprocessor will disable the clock and proceed to step 1308. In step 1308, the secure coprocessor will return the operation to the controller operating in user mode.

[0064] In Figure 11A a simple capacitor circuit example that can be used to detect such a persistent clock high state is depicted. Among these, the time constant of the capacitor circuit should be adjusted such that a clock signal operating at the lowest frequency at which the controller is designed does not trigger a change in the binary state of the capacitor. This can be achieved by ensuring where f min is the minimum operating frequency of the CAN controller. Figure 12 A similar discharge circuit illustrated therein can be used to detect a gated clock in the low (0) state.

[0065] Figure 14 is a flowchart 1400 of the peripheral device status check function via a transition to the secure operation mode. In step 1402, the controller (e.g., controller 102, 202) proceeds to step 1404 if a clock disable instruction is issued while the controller is in the user-level operation mode. In step 1404, the controller transitions to the secure operation mode (e.g., from user mode to supervisor mode, from application mode to kernel mode). In step 1406, while in the secure operation mode, the controller executes a peripheral device status check function such as Figure 12 illustrated therein. For example, while in the secure operation mode, the controller checks whether an attempt to disable the clock occurred during a partial transfer. This may include reading and / or writing registers that are inaccessible in the non-secure operation mode. If so, while in the secure operation mode, the controller will reset the controller data as in step 1206, reset the transfer buffer as in step 1208, or both. Then, the controller will disable the clock and proceed to step 1408. In step 1408, the controller will transition from the secure operation mode to the non-secure operation mode (e.g., user mode, application mode).

[0066] For both systems, the reset generation mechanism simply consists of a buffer that can be connected to the asynchronous reset pins of the controller elements. Alternatively, the reset signal can be connected to the reset pin of the entire peripheral device or used to trigger a hardware interrupt to reset the controller state.

[0067] Figure 15 is via the compiler function 1500 to useFigure 12 Flowchart of a peripheral device status check function for filling clock disable. In this embodiment, the compiler includes a clock disable function, where the clock disable includes a peripheral device status check function before performing the clock disable. During code generation, when a programmer enters a clock disable function (e.g., disable CAN clock, disable Ethernet clock) for a communication peripheral such as in step 1502, the compiler will insert code to execute the peripheral device status check function (function call, inline code, or a combination thereof). In step 1504, the code is processed via the compiler / assembler / linker to generate instructions for the processor. In step 1506, the compiler replaces the clock disable call with the status check function.

[0068] Although this example is for a compiler, this can also be used in a virtual machine environment, such as JAVA, Parrot virtual machine, Common Language Runtime (CLR), or other runtime virtual machines.

[0069] Another embodiment is a system and method for using trusted control of a peripheral clock to provide a protection operation for a CAN controller. In the case where the CAN controller is integrated with a processor and typically packaged in a single package, the ability to execute CLKON / CLKOFF from unprivileged software is a key component in enabling an attack. In many cases, these systems typically perform checks to ensure that the transmit buffer is flushed to the software designer. While such low-level control provides greater control to the system designer, it can be misused by an adversary.

[0070] The purpose of the CLKON / CLKOFF feature is to optimize chip power consumption, and thus, based on usage, the application software does not need it frequently. To prevent misuse, such functionality can be offloaded to a trusted code segment, such as a low-level device driver or component running in a secure module (such as a Hardware Security Module (HSM)) that verifies the controller state before disabling the clock.

[0071] Figure 16 It is a block diagram of a communication system 1600 including a monitoring node 1606, an attacker node 1604, and a target node 1602. The monitoring node 1606 includes a microcontroller 1608, a communication controller 1610 (e.g., CAN controller, Ethernet controller), a communication transceiver 1612 (e.g., CAN transceiver, Ethernet transceiver), and a short circuit or shunt device. The shunt can be a Metal Oxide Semiconductor Field Effect Transistor (MOSFET), Bipolar Junction Transistor (BJT), relay, or other switching component.

[0072] An embodiment of an MCU with a secure processor (or HSM) can be implemented via an architecture with a clock state change request function, which can be implemented as an interruption to the secure processor (or enclave). The secure processor includes a direct request (activation or deactivation) to change the peripheral clock state, and an alternative request includes a mode change request to change the peripheral clock state based on mode rules (e.g., HALT mode, STOP mode, SAFE mode, TEST mode, etc.). The peripheral device status check function can run within the secure processor or trusted environment and includes checking the status register of the peripheral device for an active transfer buffer (non-empty buffer or buffer being actively transferred), checking the bus status of the peripheral device, such as an active transfer from a device in the network.

[0073] A system or method using signed (or trusted) code can replace the default peripheral device status check function. This system or method will ensure that the user still has low-level control, however, this control can only be exercised within a secure enclave.

[0074] In the case of an MCU without a secure coprocessor (or HSM), an embodiment implementing such request and check functionality can be via a low-level driver implemented in firmware. In another embodiment where an integrated circuit (e.g., a processor, embedded processor, microcontroller, ASIC, etc.) provides a custom compiler (or extension), the compiler can add logic for implementing such checks for each peripheral device request in order to convert high-level code into low-level binaries.

[0075] Another embodiment includes a list of trusted authorities and a method for verifying cryptographic signatures from trusted authorities, where the protected peripheral device status function can be defined by the user by providing a trusted instruction composed of instructions and a cryptographic signature over the instructions issued by a trusted authority in the list.

[0076] It should be noted that adding such instructions, subroutines, functions, etc. to the compiler using techniques such as return-oriented programming does not protect against adversaries directly manipulating runtime software. However, these additions can provide an additional layer of robustness, which can be used in combination with other techniques disclosed herein.

[0077] The next step is to cut off the attacker. The methods disclosed herein can be used to improve the robustness and security of controllers controlled by adversaries. In scenarios where an adversary manages to bypass all such protections, additional countermeasures can be implemented in other nodes connected to the bus, which can disable (or attack) the adversary, thereby minimizing the damage that the adversary may cause.

[0078] First, assume that some nodes on the network have additional monitoring capabilities that can be used to detect such bit-insertion attacks. These nodes can include powerful nodes such as gateway ECUs or body controllers.

[0079] After detecting malicious behavior, the node can impose an injected recessive bit during the malicious error frame injection of the attacking ECU. To insert such a bit, the node requires the following additional components,

[0080] A switch in the CAN transceiver (e.g., a metal-oxide-semiconductor field-effect transistor (MOSFET), bipolar junction transistor (BJT), gate, bridge, or relay) that can bridge the connection between the CAN bus lines (e.g., CANH and CANL). Using the switch triggers an intentional short-duration short circuit on the CAN bus. This intentional short circuit can typically be handled by the node without problems.

[0081] The imposed recessive bit signal can be used to activate the switch. Such a signal can typically be provided by adding additional logic to act as an interface between the controller and the transceiver.

[0082] In one embodiment, in the case where the detection logic is present in the processor and not in the CAN controller, an additional signal is required between the MCU and the CAN controller, and the additional signal can be used to signal the imposition of a recessive bit. In another embodiment, the signal can be directly connected between the MCU and the transceiver, thus bypassing the controller.

[0083] Such an ability can be used to trigger a bit fault in the attacker, causing it to enter the bus-off (or reset) state. It should be noted that the addition of such an ability requires deviation from the typical design of the CAN transceiver and controller, thus requiring additional capabilities. Such an addition must be performed while conforming to the CAN protocol.

[0084] In a scenario where the attacker node transmits and can be identified using the physical characteristics of the transmission (such as clock offset, voltage level, or transients), the node can be disabled by truncating any recessive bits during the adversary setup phase (e.g., in the data length segmentation of the message). Such a method requires additional low-level detection capabilities but does not require additional circuitry to bridge the bus lines. Instead, it requires the CAN controller to have the ability to inject an imposed dominant bit, which can be used to transmit a bit even when the node is not in bus control.

[0085] The attack may rely on the same functionality implemented in software, so the injection of the imposed bit can be controlled by a secure coprocessor (or HSM).

[0086] The program code embodying the algorithms and / or method techniques described herein can be distributed, either alone or in combination, as a program product in many different forms. The program code can be distributed using a computer-readable storage medium having computer-readable program instructions thereon for causing a processor to implement aspects of one or more embodiments. A tangible computer-readable storage medium can include volatile and non-volatile, removable and non-removable media implemented in any method or technology for information storage, such as computer-readable instructions, data structures, program modules, or other data. The computer-readable storage medium can further include RAM, ROM, erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other solid state memory technologies, portable compact disc read-only memory (CD-ROM) or other optical storage devices, cassette tapes, magnetic tape, magnetic disk storage devices or other magnetic storage devices, or any other medium that can be used to store the desired information and that can be read by a computer. The computer-readable program instructions can be downloaded from a computer-readable storage medium to a computer, another type of programmable data processing apparatus, or another device, or downloaded to an external computer or external storage device via a network.

[0087] The computer-readable program instructions stored in the computer-readable medium can be used to cause a computer, other type of programmable data processing apparatus, or other device to operate in a particular manner, such that the instructions stored in the computer-readable medium produce an article of manufacture including instructions for implementing the functions, acts, and / or operations specified in the flowchart or diagram. In certain alternative embodiments, the functions, acts, and / or operations specified in the flowchart and diagram can be reordered, processed serially, and / or processed simultaneously in accordance with one or more embodiments. Additionally, any flowchart and / or diagram can include more or fewer nodes or blocks than those illustrated consistent with one or more embodiments.

[0088] Although all of the content of the present invention has been illustrated by the description of various embodiments, and although these embodiments have been described in considerable detail, the applicant does not intend to limit or in any way restrict the scope of the appended claims to such details. Additional advantages and modifications will be readily apparent to those skilled in the art. Accordingly, the present invention in its broader aspects is not limited to the specific details, representative apparatus and methods, and illustrative examples shown and described. Thus, departures from such details can be made without departing from the spirit or scope of the general inventive concept.

Claims

1. An electronic control unit (ECU) comprising: A processor; A controller area network (CAN) controller having a state and configured to Receive data and control signals from the processor and receive a clock signal, Encapsulate the data to create a CAN protocol frame stored in at least one transmission buffer, and Shift the CAN protocol frame to a CAN transceiver configured to transmit the CAN protocol frame to a CAN bus; Clock gating logic configured to selectively disable the clock signal to the CAN controller based on a control signal from the processor; And Security gating logic configured to prohibit disabling the clock signal in response to the state of the CAN controller being active.

2. The electronic control unit according to claim 1, wherein, The state is active if the CAN controller is actively transmitting a CAN protocol frame.

3. The electronic control unit according to claim 2, wherein, The state is active if at least one transmission buffer has data for transmission such that if any bit of the at least one transmission buffer is a logic 1, the inhibit clock stop signal is asserted.

4. The electronic control unit according to claim 1, further comprising a data transfer gate and a control signal transfer gate, wherein, Prohibit the transmission of data and control signals through data transfer gates and control signal transfer gates based on the control signal.

5. The electronic control unit according to claim 1, wherein the security gating logic includes an inhibit clock stop signal asserted during a period in which the at least one transmission buffer has a value greater than zero and de-asserts the inhibit clock stop signal in response to completion of transmission of an end-of-frame (EoF) from a shift buffer.

6. The electronic control unit according to claim 1, wherein the security gating logic is further configured to reset the CAN controller when a clock enable signal is inactive.

7. The electronic control unit according to claim 1, wherein the CAN bus includes CAN high and CAN low signals and the CAN transceiver is further configured to short the CAN high and CAN low signals.

8. The electronic control unit according to claim 1, wherein the security gating logic is further configured to detect non-conforming CAN frames on the CAN bus.

9. The electronic control unit according to claim 8, further comprising a connection between the CAN controller and the CAN transceiver, wherein, In response to detecting a non-conforming CAN frame on the CAN bus, force a recessive bit onto the CAN bus.

10. The electronic control unit according to claim 8 further includes a connection between the processor and the CAN transceiver, wherein, In response to detecting a non-conforming CAN frame on the CAN bus, force a recessive bit onto the CAN bus.

11. An electronic control unit (ECU) comprising: A processor; A controller configured to Receive data and control signals from the processor, Encapsulate the data to create a protocol frame stored in at least one transmission buffer, and Serially shift the protocol frame through a shift buffer to a transceiver configured to receive serial data from the controller and transmit signals on a bus; Clock gating logic configured to selectively disable the clock to the controller based on a signal from the processor; And Security gating logic configured to prohibit disabling the clock in response to the state of the controller being active.

12. The electronic control unit according to claim 11, wherein the controller is an Institute of Electrical and Electronics Engineers (IEEE) 802 Ethernet controller, the protocol frame is an Ethernet protocol frame, the transceiver is an Ethernet transceiver, and the bus is an Ethernet bus.

13. The electronic control unit according to claim 11, wherein, The controller is a Controller Area Network (CAN) controller, the protocol frame is a CAN protocol frame, the transceiver is a CAN transceiver, and the bus is a CAN bus; The controller is a Controller Area Network (CAN) controller, the protocol frame is a Local Interconnect Network (LIN) protocol frame, the transceiver is a LIN transceiver, and the bus is a LIN bus; or The controller is a Flexray controller, the protocol frame is a Flexray protocol frame, the transceiver is a Flexray transceiver, and the bus is a Flexray bus.

14. The electronic control unit according to claim 13, wherein the safety gating logic includes a continuous clock detection signal that is generated when the clock does not change state for a period greater than a minimum acceptable clock period.

15. The electronic control unit according to claim 13, wherein the safety gating logic is further configured to detect non-conforming CAN frames on the CAN bus and, in response to detecting a non-conforming CAN frame on the CAN bus, force a recessive bit onto the CAN bus.

16. An electronic control unit (ECU) comprising: a processor; a controller configured to receive data and control signals from the processor, encapsulate the data to create a protocol frame stored in at least one transmit buffer, and serially shift the protocol frame to a transceiver via a shift buffer, the transceiver being configured to receive serial data from the controller and transmit the protocol frame on a bus; clock gating logic configured to selectively disable the clock to the controller based on a control signal from the processor; safety gating logic configured to prohibit disabling the clock in response to a controller state indicating an active transmission of a protocol frame; and reset logic configured to reset the at least one transmit buffer when the control signal transitions from active to inactive.

17. The electronic control unit according to claim 16, wherein the reset logic outputs a reset signal asynchronous to the clock.

18. The electronic control unit according to claim 16, wherein the reset logic outputs a reset signal synchronous to the clock.

19. The electronic control unit according to claim 18, wherein the synchronous reset signal is generated by a buffer that is connected to a first D flip-flop triggered by a positive clock edge and a second D flip-flop triggered by a negative edge.

20. The electronic control unit according to claim 16, wherein the safety gating logic includes a continuous clock detection signal that is generated when the clock does not change state for a period greater than a minimum acceptable clock period.

Images