Clock control to increase robustness of serial bus interface

Abstract

Clock control to increase robustness of serial bus interface. A computer system for performing electronic control unit (ECU) control, the electronic control unit (ECU) having a processor for executing computer readable instructions and a memory for maintaining computer executable instructions, the computer executable instructions, when executed by the processor, perform the following functions. The functions include configuring a communication controller to transition to a non-safe mode when operating in a safe mode; executing a program utilizing the communication controller in the non-safe mode; and in response to detecting a clock off request when a transmit buffer of the communication controller is not empty, disabling the clock off request until the transmit buffer is empty.

Description

TECHNICAL FIELD

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

[0002] Modern vehicles include multiple electronic control units (ECUs). Most of these ECUs communicate via a communication bus using a communication protocol, such as a 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 made many advances in vehicle operation. However, along with additional functionality, these in-vehicle networks have become a primary target of automotive cyber attacks. SUMMARY

[0003] A computer-implemented method for controlling a clock enable signal associated with a communication system, comprising: configuring, by a processor, a communication controller to communicate according to a protocol when operating in a secure mode; transitioning to a non-secure mode; executing a program in the non-secure mode that utilizes the communication controller to communicate via the protocol; receiving a request to stop a clock of the communication controller; and in response to a transmit buffer of the communication controller not being empty, disabling the stop clock, and in response to the transmit buffer being empty, stopping the clock.

[0004] A method for controlling a clock signal associated with a communication system, the method comprising: receiving the clock signal; receiving a status signal indicating an active or inactive communication system; receiving a clock disable signal; in response to the status signal being active, passing the clock signal; and in response to the status signal being inactive, disabling the clock signal.

[0005] A computer system for performing electronic control unit (ECU) control, the electronic control unit (ECU) having a processor for executing computer readable instructions and a memory for maintaining computer executable instructions that, when executed by the processor, perform the following functions. The functions include configuring a communication controller to transition to a non-secure mode when operating in a secure mode; executing a program in the non-secure mode that utilizes the communication controller; and in response to detecting a clock off request when a transmit buffer of the communication controller is not empty, disabling the clock off request until the transmit buffer is empty. BRIEF DESCRIPTION OF DRAWINGS

[0006] Figure 1 is a block diagram of a controller area network (CAN) stack in an electronic control unit (ECU).

[0007] Figure 2is 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 via state and enable for a CAN controller.

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

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

[0014] Figure 9 is a block diagram of a reset circuit to reset a transmit buffer via an asynchronous reset signal.

[0015] Figure 10 is a block diagram of a reset circuit to reset a transmit buffer via a synchronous reset signal.

[0016] Figure 11A is a block diagram of a detection circuit to detect a continuously high clock signal.

[0017] Figure 11B is a block diagram of a detection circuit to detect a continuously low clock signal.

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

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

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

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

[0022] Figure 16 is a block diagram of a communication bus including a supervisory node, an attacker node, and a target node. DETAILED DESCRIPTION

[0023] As required, detailed embodiments of the present application are disclosed herein; however, it is to be understood that the disclosed embodiments are merely representative of the application, which can be embodied in various and alternative forms. The Figures are not necessarily to scale; some features can be exaggerated or minimised for purpose of clarity. Therefore, specific structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a representative basis for teaching one skilled in the art to variously employ the present application.

[0024] The term "substantially" can be used herein to describe an embodiment that is disclosed or claimed in the present disclosure. The term "substantially" can modify an 0%, 0.1%, 0.5%, 1%, 2%, 3%, 4%, 5%, or 10%.

[0025] Security mechanisms that prevent remote software based attacks on nodes connected to a Controller Area Network (CAN) bus assume that counter actions are limited to exploiting messages that adhere to the ISO-11898 / 1, ISO-11898 / 2, ISO-11898 / 3, etc. physical layer specifications that govern message framing and timing. However, this assumption is no longer sufficient for ECUs that utilize the CAN bus. This disclosure describes software methods that can be used to transmit messages that do not conform to the CAN specification by misusing CAN controller functionality. Also, novel methods are disclosed that use 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 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 ISO 11783. Furthermore, these concepts can be applied to other serial bus architectures such as Ethernet (IEEE 802.11 and variants thereof), Local Interconnect Network (LIN), Flexray (ISO 17458-1 through 17458-5).

[0026] The CAN bus is a central communication network used in many systems including automotive systems, aerospace systems, consumer systems, and industrial systems. Adding remote interfaces on some nodes on the bus creates vulnerabilities and opens these systems to remote attacks. These vulnerabilities have become an operational and safety concern. 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 of CAN and computing power of typical nodes on the network, the difficulty of integrating security into the network has increased significantly. Techniques to address this challenge include novel key agreement mechanisms, lightweight authentication schemes, and the use of specialized intrusion detection systems (IDS). Several of these mechanisms assume that an adversary's actions are limited to software on a compromised node, thus providing the attacker with the ability to inject arbitrary CAN compliant messages. Such an assumption allows the security mechanisms to be designed optimally.

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

[0029] Turning to software-based bit insertion, Figure 1 A layer structure of a conventional node on a CAN bus is illustrated in FIG. 1. Figure 1 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, embedded processor, processor, Application Specific Integrated Circuit (ASIC), Field Programmable Gate Array (FPGA), or similar device. The processor 102 communicates with a CAN controller 104 by sending and receiving data such as message IDs and data payloads. The CAN transceiver 106 is the interface between the CAN protocol controller 104 and the physical wires of the CAN bus line. The CAN bus line is 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 with the receive (RX) of the CAN transceiver 106, and the RX on the CAN controller 104 is coupled with the TX of the CAN transceiver 106.

[0030] As with traditional layered designs, a conventional and common assumption is that the interaction between layers only occurs at the message sending interface. In a traditional CAN stack, the CAN controller monitors the bus for transmitted packets and guarantees that all transmitted messages are compliant with the CAN protocol.

[0031] A CAN controller accepts data payloads and message IDs from an application and sends CAN compliant message frames to a CAN transceiver, which transmits analog signals on the bus (i.e., physical wires). The controller ensures proper contention resolution operations, such as backing off if the arbitration between two simultaneous transmitters is lost, thereby ensuring proper transmission of error frames, message ID filtering, and maintenance of interframe spacing (IFS).

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

[0033] In some modern ECUs, the CAN controller and processor are part of the same physical package, which can be implemented as a multi-chip module (MCM) or by integrating the CAN controller peripherals with the processor monolithically, thereby exposing new interfaces to the MCU, including a clock control interface and a power control interface. As Figure 2 The new interfaces are typically not visible to the application and are used by low-level device drivers to optimize chip power consumption and usage during debugging operations. However, malicious software can exploit such interfaces 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 chosen such that the desired CAN bus nominal bit time (NBT) is an integer number of time quanta (CAN system clock periods), e.g., from 8 to 25. For example, consider a bit rate of 125k bits per second, a bus length = 50m, a bus propagation delay = 5 x 10-9 sm-1, a propagation delay of the physical interface (transmitter plus receiver) at 85C of 150ns, and an MCU oscillator frequency = 8MHz. A prescaler value of 4 gives the CAN system a clock of 2MHz and a time quantum of 500ns. This would give 8000 / 500 = 16 time quanta per bit.

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

[0035] Figure 3 is a flowchart of an attack precursor 300 to a CAN controller via arbitrary bit insertion. In step 302, a controller (e.g., controller 102, 202) enables a clock to a 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 an interframe space (IFS) detection (e.g., a sequence of recessive bits after an end of frame (EOF) transmission) received from the CAN controller (e.g., controller 104, 204). In step 308, the controller (e.g., controller 102, 202) sends a packet to a buffer of the CAN controller (e.g., controller 104, 204) (e.g., ID 0x00 and payload 0101010). Since the ID of 0x00 is 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 the arbitration field (ARB) portion of a CAN message. In step 310, the controller (e.g., controller 102, 202) waits for the arbitration to complete via the arbitration (ARB) field and data length code (DLC) in the control (CTRL) field indicating a 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 manipulation of the CAN bus by the CAN controller (e.g., controller 104, 204) affecting other modules on the CAN bus.

[0036] Figure 4is a flowchart of an attack 400 by a CAN controller inserting a single dominant bit for an arbitrary duration. In step 402, a controller (e.g., controller 102, 202) initiates an attack on a CAN bus via a message sent to a CAN controller (e.g., controller 104, 204). In step 404, the controller (e.g., controller 102, 202) waits for a target message to be sent to the CAN controller (e.g., controller 104, 204). Here, the end of the wait period can be triggered by an external signal or start-of-frame (SOF), which is a single dominant bit preceded by at least 11 recessive bits. In step 406, the controller (e.g., controller 102, 202) enables the clock to the CAN controller (e.g., controller 104, 204) with the dominant bit transmitted by the CAN controller. In step 408, the controller (e.g., controller 102, 202) disables the clock to the CAN controller (e.g., controller 104, 204) while asserting a 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 a 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 a general method of transmitting a dominant bit (0 bit) of arbitrary length on a CAN bus with the new interface is illustrated. The CLK OFF / CLK ON operation denotes the action of disabling and enabling the peripheral clock (clock gating) to the CAN controller. The implementation details of this operation vary from MCU / ECU to MCU / ECU. For example, the method using Arduino Due is to utilize the low-level command available in the software development kit (SDK), (e.g., pmc_disable_periph_clk). Similarly, for different MCUs, the method of low-level timing measurement for the synchronization action varies.

[0038] The attack exploits a message with ID 0x00 and an 8-byte payload with alternating zeros and ones (0101 ··· 01). The example 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 a return-to-ready (RTR) bit transmission, a CLKOFF command is issued to freeze the state of the CAN controller (e.g., controller 104, 204). This prepares the controller (e.g., controller 102, 202) for transmission of a message. After identification of the target message, the second attack phase begins. This consists of transmission of the first dominant bit of the payload using a CLKON command. Then, a 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 is transitioned to the recessive state by successive CLKON and CLKOFF signal transitions.

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

[0040] The present disclosure describes new methods to protect ECUs (e.g., 100, 200) / CAN controllers / Ethernet controllers (e.g., controller 104, 204) from being used to transmit non-compliant messages. With respect to the CAN standard, all messages are generally referred to as frames, which include data frames, remote frames, error frames, and overload frames. Information sent to the CAN bus must conform to defined frame formats of different but limited lengths. Non-compliant CAN frames include frames that do not meet the specifications documented by the International Organization for Standardization (ISO) in the CAN standard ISO 11898. Advantages of these systems and methods include:

[0041] First, methods to protect existing CAN systems against a new class of adversaries that were previously unknown and not protected against.

[0042] Second, the methods are applied at different layers (e.g., hardware, application software, firmware, or built into a compiler), providing a system designer with multiple options based on the specific architecture. 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 wide variety of systems that utilize CAN networks, such as automobiles, aerospace systems, industrial control systems, building control technology. Furthermore, the disclosed methods can be applied to general systems where clock control can be utilized to drive a peripheral into an undesired state.

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

[0045] Preventing clock disable is a key aspect of preventing attacks on the CAN controller to disable the ability to arbitrarily disable the clock and thus pause the state of the CAN controller in the middle of a transmission. Disabling the clock enables the attacker to potentially transmit partial and selective message bits. Preventing the clock from being disabled at arbitrary times is a technique to prevent arbitrary control.

[0046] Based on the implementation of the clock gating logic, several designs are possible for controlling the clock disable feature. Figure 5 Fig. illustrates an example of a conventional clock gating mechanism using an active high enable signal. Figure 5 is a block diagram of an ECU 500 with 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 an input / output (I / O) pin that can be used to gate the clock via logic 506, such as an AND gate. The I / O pin performs the CAN enable function to gate the clock. Figure 6 is a block diagram of clock gating via state and enable for a CAN controller.

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

[0048] Figure 8is a block diagram 800 of a CAN controller 802 with a transmit buffer state based on the value of the 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 sent via the CAN Tx. The transmit buffer(s) 806 also include logic 808 to generate a controller state 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 into a low power mode by continuously adding data to the transmit buffer. This can be exploited by an adversary and can cause a denial of service (DoS) attack by the 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 in FIG. 7, where the entire interface between the MCU and the controller is disabled if the clock signal to the controller is disabled. Based on the specific implementation, only a subset of the interface signals responsible for initiating new activity can be disabled. Figure 7 is a block diagram of an ECU 700 with gated clock, data bus, and control bus for a CAN controller. 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 qualified by additional logic 708, such as a signal from the CAN controller 704 indicating the CAN controller state.

[0050] Reset for clock disable is another circuit and method to protect the integrity of CAN communication. This is based on the enabling factor of the attack to become persistent in the CAN controller state after the clock is disabled. Therefore, an alternative mitigation strategy can be to ensure that the controller is reset to a safe or initialized state if the clock is disabled for a sufficiently long duration. Based on the architecture of the CAN controller, several designs are feasible to ensure the reset of the controller state.

[0051] In a simple solution, a reset system is designed using the 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 sequential logic elements, the system can generate a synchronous or asynchronous reset signal.

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

[0053] Figure 9 is a block diagram of a reset circuit to reset the transmit buffer via an asynchronous reset signal. The CAN controller has a shift register 904 configured to convert data from the transmit buffer(s) 906 into a serial data stream to be sent via the CAN Tx. The transmit buffer(s) 906 also include logic 908 to generate a reset of the transmit buffer(s) 906 based on a clock enable input. The logic 908 can include a delay buffer.

[0054] Figure 10 is a block diagram of a reset circuit to reset the transmit buffer via a synchronous reset signal. The CAN controller has a shift register 1004 configured to convert data from the transmit buffer(s) 1006 into a serial data stream to be sent via the CAN Tx. Logic 1008 is used to generate a synchronous reset signal. The logic 1008 can include a DQ 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 the clock enable signal is used to directly and asynchronously reset the transmit buffer. Figure 10 An alternative method for synchronously resetting the timing elements is illustrated in The combination of a D flip-flop triggered by the inverted clock edge and a sufficiently large delay buffer on the input is used to ensure that the transmit buffer is reset as soon as the clock signal is disabled. To ensure proper operation, the delay of the input buffer (d buf ) should be larger than the clock skew (t skew ) of the controller. 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 that is comprised of the 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 a multiple of 1.5, 2, 3, 4, 5, 10, 20 of the maximum clock period or other appropriate period-based time.

[0059] a clock low hold detection circuit that is comprised of the 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 the controller elements.

[0061] Figure 11A is a block diagram of a CAN control system 1100 with a CAN controller 1102 having a detection circuit 1110 to detect a sustained high clock signal, the detection circuit 1110 having a reset circuit 1108 configured to reset the CAN controller 1102 and 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 sent via the CAN Tx. The CAN controller 1102 also includes sustained clock detection logic 1110 and a reset circuit 1108 to generate a reset of the transmit buffer(s) 1106. The sustained clock detection logic 1110 is configured to detect a sustained high clock signal. Figure 11B illustrates an alternative embodiment that is a block diagram of a detection system 1150 having a detection circuit 1152 to detect a sustained low clock signal.

[0062] Figure 12is a flowchart of a peripheral status check function 1200. In step 1202, a controller (e.g., controller 102, 202) checks the status of a peripheral module (e.g., CAN controller, Ethernet controller, etc.) that it brought out of operation (the restoration of the peripheral includes resetting the transmit buffer to zero, reinitializing the peripheral, re-executing the peripheral initialization, etc.). Step 1202 is the start of the function, which is called if someone attempts a clock disable during a partial transfer. In step 1204, the controller (e.g., controller 102, 202) checks if an attempt to disable the clock occurred during a partial transfer. 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 reinitializing the peripheral, re-executing the peripheral initialization, or toggling the module reset via a pin or register. 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 acknowledge the clock disable clock signal. If the transmit buffer is empty in step 1204, the controller will skip to step 1210.

[0063] Figure 13 is a flowchart 1300 of a peripheral status check function via a secure co-processor. In step 1302, a controller (e.g., controller 102, 202) proceeds to step 1304 if it issues a clock disable instruction while the controller is in a user-level mode of operation. In step 1304, the controller transitions to operation via a secure co-processor (e.g., secure co-processor, hardware security module, TrustZone (in select ARM processors), Secure Guard Extension (SGX) (in select Intel processors), Secure Encrypted Virtualization technology (in select AMD processors), Trusted Platform Module), or more generally through a Trusted Execution Environment (TEE), which can be bootstrapped by a secure processor or co-processor, but it can also be instantiated via a combination of software and hardware. The TEE should run in an isolated environment in which operations on data, code, or a combination of the two are run securely (where secure refers to the integrity of the data, but can 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 co-processor executes a peripheral status check function, such as Figure 12The peripheral device status check function is illustrated in the diagram. For example, the security coprocessor checks whether an attempt to disable the clock occurred during a partial transfer. If so, the security coprocessor will reset the controller data as in step 1206, reset the transfer buffer as in step 1208, or both. Then, the security coprocessor will disable the clock and proceed to step 1308. In step 1308, the security coprocessor will return the operation to the controller operating in user mode.

[0064] exist Figure 11A The example depicts a simple capacitor circuit that can be used to detect such a sustained clock high state. In this circuit, the time constant of the capacitor circuit should be adjusted so that a clock signal operating at the lowest frequency the controller is designed to operate at does not trigger a change in the binary state of the capacitor. This can be achieved by ensuring… To achieve this, where f min It is the minimum operating frequency of the CAN controller. Figure 12 The similar discharge circuit shown in the diagram can be used to detect the gated clock in the low (0) state.

[0065] Figure 14 This is a flowchart 1400 of a peripheral device state check function that transitions to a secure operating mode. In step 1402, if the controller (e.g., controller 102, 202) issues a clock disable command while in user-level operating mode, it proceeds to step 1404. In step 1404, the controller transitions to a secure operating mode (e.g., from user mode to supervisory mode, from application mode to kernel mode). In step 1406, while in secure operating mode, the controller performs actions such as... Figure 12 The peripheral device status check function is illustrated in the diagram. For example, when in secure operating mode, the controller checks whether an attempt to disable the clock occurred during a partial transfer. This might include reading and / or writing to registers inaccessible in non-secure operating mode. If so, the controller will reset the controller data as in step 1206, reset the transfer buffer as in step 1208, or both, while in secure operating mode. The controller then disables the clock and proceeds to step 1408. In step 1408, the controller transitions from secure operating mode to non-secure operating 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 pin of the controller element. 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 It is used via compiler function 1500.Figure 12 Flowchart of a clock disable peripheral status check function. In this embodiment, the compiler includes a clock disable function in which the clock disable includes a peripheral status check function prior to performing the clock disable. During code generation, when the programmer enters a disable clock function (e.g., disable CAN clock, disable Ethernet clock) to the communication peripheral, such as in step 1502, the compiler will insert code to perform the peripheral 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 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 to provide a protected operation to a CAN controller with trusted control of the peripheral clock. In the case where the CAN controller is integrated with the processor and typically packaged in a single package, the ability to perform CLKON / CLKOFF from non-privileged software is a critical component in enabling attacks. 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 status prior to disabling the clock.

[0071] Figure 16 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 shorting or shunt device. The shunt can be a metal oxide semiconductor field effect transistor (MOSFET), a bipolar junction transistor (BJT), a relay, or other switching component.

[0072] One 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 interrupt to the secure processor (or enclave). The secure processor includes direct requests to change the state of a peripheral clock (activate or deactivate), and alternative requests include mode change requests to change the state of a peripheral clock based on a mode rule (e.g., HALT mode, STOP mode, SAFE mode, TEST mode, etc.). A peripheral state check function can run within the secure processor or trusted environment and includes a check of a status register of a peripheral for an active transfer buffer (non-empty buffer or buffer actively transferred), a check of a bus state of a peripheral, such as an active transfer from some device in the network.

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

[0074] Another embodiment includes a list of trusted authorities and a method to verify a cryptographic signature from a trusted authority, where a protected peripheral state function can be defined by a user by providing a trusted instruction composed of instructions and a cryptographic signature over the instructions issued by a trusted authority in the list.

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

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

[0077] A next step is to cut off the attacker. The methods disclosed herein can be used to improve the robustness and security of a controller controlled by an adversary. In scenarios where the adversary manages to circumvent 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 can cause.

[0078] It is first assumed 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] Upon detection of malicious behavior, the node can impose an injected recessive bit during the malicious error frame injection attack of the ECU. To insert such a bit, the node needs the following additional components,

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

[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, where the detection logic exists in the processor and not in the CAN controller, an additional signal is needed between the MCU and the CAN controller that can be used to signal the imposition of the recessive bit. In another embodiment, the signal can be connected directly between the MCU and the transceiver, bypassing the controller.

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

[0084] In scenarios where the attacker node transmits can be identified using physical characteristics of the transmission, such as clock skew, voltage levels, or transients, the node can be disabled by deleting any recessive bits in the adversary setup phase (e.g., in the data length segment 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 imposed dominant bits that can be used to transmit bits even when the node is not in bus control.

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

[0086] Program code embodying aspects of the algorithms and / or methods described herein can be distributed over network coupled computer systems so that the computer readable code portions are stored and executed in a distributed fashion. Computer readable storage media storing computer readable instructions that, when executed, can cause a processor to perform aspects of the present disclosure can include volatile and nonvolatile, removable and non-removable media implemented in a method or technology such as RAM, ROM, Electrically Programmable Read Only Memory (EPROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other solid state memory technology, portable compact disc read-only memory (CD-ROM), or other optical storage, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information in a non-transitory fashion and which can be read by a computer. Computer readable program instructions can be downloaded to a computer, another type of programmable data processing apparatus, or another device from a computer readable storage medium or to an external computer or external storage device via a network.

[0087] Computer readable program instructions stored in a computer readable medium can be used to direct a computer, other types of programmable data processing apparatuses, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function, action and / or operations specified in the flowcharts or illustrations. In some alternative implementations, the function, action and / or operations specified in the flowcharts or illustrations can be reordered, processed serially, and / or processed concurrently in a manner consistent with one or more implementations. Also, any flowcharts or illustrations can include more or fewer nodes or blocks than those illustrated.

[0088] While the present application has been illustrated by the description of various embodiments, and while these embodiments have been described in considerable detail, it is not the intention that the application be limited thereto. Additional advantages and modifications will readily occur to those skilled in the art. Therefore, the application in its broader aspects is not limited to the specific details, representative apparatus, and illustrative examples shown and described. Accordingly, departures can be made from such details without departing from the spirit or scope of the general inventive concept.

Claims

1. A computer-implemented method for controlling a clock enable signal associated with a communication system, the method comprising: by a processor, configuring a communication controller to communicate according to a protocol when operating in a secure mode; transitioning to a non-secure mode; executing a program in the non-secure mode that utilizes the communication controller to communicate via the protocol; receiving a request to stop a clock of the communication controller; and inhibiting stopping the clock in response to a transmit buffer of the communication controller being non-empty, and stopping the clock in response to the transmit buffer being empty.

2. The computer-implemented method of claim 1, wherein, the processor includes a secure co-processor that requires special privileges for executing instructions, and the clock is inhibited from being stopped via a protected software routine executing on the secure co-processor.

3. The computer-implemented method of claim 1, wherein, the processor includes a hardware security module that generates an interrupt for the processor, and the clock is inhibited from being stopped via a protected software routine executing on the hardware security module.

4. The computer-implemented method of claim 1, further comprising transitioning to a secure mode in response to receiving the request to stop the clock of the communication controller, wherein the transition from the non-secure mode to the secure mode is via an interrupt or a system call.

5. The computer-implemented method of claim 1, wherein, the non-secure mode operates in a virtual machine environment.

6. The computer-implemented method of claim 1, wherein, stopping the clock is implemented by translating a high-level software program into instructions that can be executed on the processor and inserting instructions for each request to stop the clock if the transmit buffer of the communication controller is non-empty and if the transmit buffer is empty.

7. The computer-implemented method of claim 1, wherein, the transition to the non-secure mode is from a user mode to a supervisor mode or from a user mode to a kernel mode.

8. The computer-implemented method of claim 1, wherein, the transition to the non-secure mode is from executing instructions by the processor to executing instructions by a co-processor monolithically integrated with the processor.

9. A method for controlling a clock signal associated with a communication system, the method comprising: receiving the clock signal; receiving a status signal indicating an active or inactive communication system; receiving a clock disable signal; passing the clock signal in response to the status signal being active; inhibiting the clock signal in response to the status signal being inactive; inhibiting stopping the clock in response to a transmit buffer of the communication controller being non-empty; and stopping the clock in response to the transmit buffer being empty.

10. The method of claim 9, wherein, the method is executed on a secure co-processor that requires special privileges for executing instructions, and the clock signal is inhibited from being stopped via a protected software routine executing on the secure co-processor.

11. The method of claim 9, wherein, the method is executed on a processor that includes a hardware security module that generates an interrupt for the processor, and the clock signal is inhibited from being stopped via a protected software routine executing on the hardware security module.

12. The method of claim 9, wherein, the method further comprises transitioning to a secure mode in response to receiving the clock disable signal, wherein the transition from the non-secure mode to the secure mode is via an interrupt or a system call.

13. The method of claim 12, wherein, the transitioning to the secure mode is from executing instructions by the processor to executing instructions by a co-processor monolithically integrated with the processor.

14. The method of claim 12, wherein, the transitioning to the secure mode is from a user mode to a supervisor mode or from a user mode to a kernel mode.

15. The method of claim 12, wherein, receiving the status signal is a protected software routine that includes a peripheral status check function to verify that the status of the communication system is inactive before inhibiting the clock signal.

16. A computer system for performing electronic control unit control, the electronic control unit having a processor for executing computer readable instructions and a memory for maintaining computer executable instructions, the computer executable instructions when executed by the processor perform the following functions: by the processor configuring a communication controller when operating in a safe mode, transitioning to a non-safe mode, executing a program utilizing the communication controller in the non-safe mode; and inhibiting a clock off request in response to detecting that a transmit buffer of the communication controller is not empty.

17. The computer system of claim 16, wherein, the processor includes a secure co-processor that requires special privileges for executing instructions and the stopping of the clock is inhibited via a protected software routine executing on the secure co-processor.

18. The computer system of claim 16, wherein, the processor includes a hardware security module that generates an interrupt for the processor and the stopping of the clock is inhibited via a protected software routine executing on the hardware security module.

19. The computer system of claim 16, further comprising transitioning to a safe mode in response to receiving a request to stop a clock of the communication controller, wherein the transitioning from the non-safe mode to the safe mode is via an interrupt or a system call.

20. The computer system of claim 16, wherein, the transitioning to the non-safe mode is from executing instructions by the processor to executing instructions by a co-processor monolithically integrated with the processor.

Images