CANNON: Reliable and Stealthy Remote ShutdownAttacks via Unaltered Automotive Microcontrollers

Sekar Kulandaivel,∗ Shalabh Jain,† Jorge Guajardo,† and Vyas Sekar∗∗Carnegie Mellon University, †Research and Technology Center, Robert Bosch LLC, USA

{skulanda, vsekar}@andrew.cmu.edu, {shalabh.jain, jorge.guajardomerchan}@us.bosch.com

Abstract—Electronic Control Units (ECUs) in modern vehicleshave recently been targets for shutdown attacks, which candisable safety-critical vehicle functions and be used as means tolaunch more dangerous attacks. Existing attacks operate eitherby physical manipulation of the bus signals or message injection.However, we argue that these cannot simultaneously be remote,stealthy, and reliable. For instance, message injection is detectedby modern Intrusion Detection System (IDS) proposals andrequires strict synchronization that cannot be realized remotely.In this work, we introduce a new class of attacks that leveragethe peripheral clock gating feature in modern automotive mi-crocontroller units (MCUs). By using this capability, a remoteadversary with purely software control can reliably “freeze” theoutput of a compromised ECU to insert arbitrary bits at anytime instance. Utilizing on this insight, we develop the CANnonattack for remote shutdown. Since the CANnon attack produceserror patterns indistinguishable from natural errors and does notrequire message insertion, detecting it with current techniques isdifficult. We demonstrate this attack on two automotive MCUsused in modern passenger vehicle ECUs. We discuss potentialmitigation strategies and countermeasures for such attacks.

Index Terms—Automotive security, CAN bus attack, Faultattacks, Glitching attacks

I. INTRODUCTION

Modern in-vehicle networks contain tens of Electronic Con-trol Units (ECUs) that communicate over a shared mediumknown as the Controller Area Network (CAN) bus. Someof these ECUs that introduce new wireless connectivity (e.g.Bluetooth, cellular, Wi-Fi), which provide a variety of servicesto vehicle owners, have exposed the in-vehicle network toexternal network attacks. The feasibility and ease of launchingattacks against the CAN bus have been demonstrated byseveral researchers over the past few years [1]–[4].

The lack of security in in-vehicle networks allows anadversary with access to the CAN bus to arbitrarily insert,modify, and delete messages, allowing an attacker to ma-nipulate the functionality of safety-critical ECUs [1] or limitcommunication over the bus [5], [6]. While traditional attacksutilize physical interfaces to gain bus access, researchers havedemonstrated the ability to gain access remotely [4]. Thisdemonstration caused the recall of 1.4 million vehicles andattracted the attention of automotive manufacturers, suppliers,and global regulatory bodies.

As a defense against an evolving threat landscape, aca-demic and industry researchers have proposed a variety oftechniques, such as message authentication [7], [8], intrusiondetection systems (IDSes) [9]–[12], and secure CAN hardware

solutions [13]. Considering the potential societal impact ofautomotive attacks, regulatory bodies have proposed intro-ducing legal mandates to equip future vehicles with securityfeatures, e.g. IDSes [14]. Even hardware defenses in the formof secure transceiver concepts [13] have been proposed toincrease security of the in-vehicle CAN bus.

Despite efforts to increase the security of automotive net-works, a recent class of attacks demonstrates significant ad-versarial potential by utilizing the inherent CAN protocolframework to shut down safety-critical ECUs. Such attacks in-troduced by prior work [5], [6], [15] are particularly dangerousdue to their ability to disable critical vehicle functionality byshutting down several ECUs from just a single compromisedECU. Additionally, an adversary could use shutdown attacks tolaunch advanced attacks, e.g. stealthy masquerade attacks [16],[17]. Current shutdown attacks repeatedly trigger the error-handling mechanism on a victim ECU, causing it to enter thebus-off error-handling state that shuts down the ECU’s CANcommunication. This attack is achieved by either physicalmanipulation of the bus [5], [6] or carefully synchronizedand crafted transmissions [15]. However, these proposals eitherlack stealthiness against existing security proposals [10], [11],[13], require physical access [5], [6], or require strict control(e.g. synchronization) that cannot be achieved in practicalremote settings [15].

In this paper, we introduce a fundamentally different ap-proach towards mounting shutdown attacks that, to the bestof our knowledge, can evade all existing known defenses.Our attack is facilitated by architectural choices made toimprove the integration and efficiency of automotive ECUs andtheir microcontroller units (MCUs). Modern MCUs typicallyintegrate the CAN interface controller as an on-chip (CAN)peripheral in the same package. This design allows new inputsto the CAN peripheral to be accessible to the application-layer software via an application programming interface (API)and, thus, accessible to a remote adversary that successfullycompromises an ECU.

We develop CANnon, a method to maliciously exploit onesuch input, namely the peripheral clock gating functionality.This particular API is accessible via software control in mostmodern automotive MCUs, often included as a valuable featurefor performance optimization. We demonstrate how a remotesoftware adversary can employ CANnon to utilize the CANperipheral’s clock to bypass the hardware-based CAN protocolcompliance and manipulate the ECU output. This capability

195

2021 IEEE Symposium on Security and Privacy

DOI 10.1109/SP40001.2021.00122

enables the adversary to inject arbitrary bits and signals(as compared to only being able to inject complete CAN-compliant frames) and gain the ability to precisely shapethe signals on the CAN bus with bit-level accuracy. Wedemonstrate that this capability can be used to perform reliableand stealthy shutdown attacks. In other words, the modernMCU design has inadvertently strengthened the capabilitiesof a remote adversary, who is no longer constrained by CANprotocol compliance.

Our main insight here is the ability to control the pe-ripheral’s clock signal to “pause” the ECU state in themiddle of a transmission (or between state transitions). Byexercising this control to selectively pause and resume anECU’s transmission, we can insert an arbitrary bit for aduration and at a time instance of our choice. This bit canbe used to overwrite a victim’s message and cause it to detecttransmission errors. We also illustrate that the pattern of errorsproduced by CANnon is difficult to distinguish from legitimateerrors on the CAN bus. Our fine control over malicious bitinsertion (rather than message insertion) makes the detectionof CANnon attacks difficult for currently proposed IDSes,as current techniques typically analyze entire messages forsigns of malicious activity. Additionally, as CANnon doesnot involve spoofing IDs or overwriting the content of amessage, even ID-based filtering at the data link layer [13]seems incapable of detecting our attack.1 Preventing CANnon-based attacks require either architectural-level changes, such asisolation or removal of the clock control, or modifying existingapproaches to specifically detect CANnon-like patterns. InTable I, we summarize existing works and contrast them withCANnon, which we further detail in Sec. II-B.Contributions: In summary, we contribute the following:

• We introduce new methods to exploit the peripheral clockgating API of automotive MCUs to bypass hardware-based CAN protocol compliance and inject arbitrary bitson the bus. In contrast to previous work, we do not exploitdiagnostic messages [4], [18], [19] and do not have tightsynchronization requirements [15].

• We present three stealthy versions of CANnon and discussmodifications to make CANnon stealthy against futuredefenses.

• We illustrate both a basic denial-of-service (DoS) attackand a targeted victim shutdown attack atop two mod-ern automotive MCUs used in passenger vehicles: theMicrochip SAM V71 MCU and the STMicro SPC58MCU. We validate the feasibility of this attack againsta 2017 Ford Focus and a 2009 Toyota Prius and achievea shutdown in less than 2ms.

• We propose several countermeasures to detect/preventCANnon attacks for legacy and future vehicles.

Organization: The remainder of this paper is organized asfollows. We provide relevant background on the CAN protocol

1Some recently proposed secure transceiver architectures use such filtering,but it is unclear from publicly available information whether they implementadditional countermeasures. We have not evaluated any such products in themarket to check their resistance against the CANnon attack.

TABLE I: Characteristics of shutdown attacks

Source Attack type Remote Reliable Stealthy[5], [6] Direct bit injection X X[1], [2], [4] Diagnostic message X X[15] Message overwrite X

CANnon X X X

and discuss existing shutdown work in Sec. II. In Sec. III, wedetail our attack insight, and we then demonstrate two practicalapplications of the attack in Sec. IV and V. We demonstrate theattack on production ECUs against real vehicles in Sec. VI andillustrate the stealth properties of CANnon in Sec. VII. Finally,we propose some countermeasures in Sec. VIII, identify otherrelated work in Sec. IX, and discuss future directions andconclusions in Sec. X.Disclosure and availability: We disclosed this vulnerabilityto several automotive stakeholders.2 Our conversations withthe MCU manufacturers (Tier-2 automotive suppliers) revealtheir emphasis on software hardening to prevent the adversarialscenario required here; thus, obligations lie with the ECUintegrators (Tier-1 automotive suppliers). We have also madethe CANnon implementation using an Arduino Due boardavailable [20] to encourage further designs using CANnon andto test defense strategies.

II. CAN PRELIMINARIES

We start with background on the CAN protocol and high-light characteristics that render CAN nodes vulnerable toshutdown attacks and discuss prior work on such attacks.

A. CAN background

ECUApplication Layer

SW App.

Data Link LayerCAN HW

Physical LayerCAN Bus

Messages

Frames

Bits

Fig. 1: CAN communication stack

The CAN protocol stack as shown in Fig. 1 is composedof the application layer, data link layer, and the physicallayer. The functionality of an ECU (e.g. engine control, driverassistance) is described via high-level software running atthe application layer. For actuation and sensing functionality,messages are transmitted and received by the application layerthrough the lower layers of the communication stack. To senddata to another ECU, the application layer creates a CANmessage with a priority tag (also referred to as message orarbitration ID) and its payload. The application transfers this

2We disclosed the vulnerability to the two MCU manufacturers discussedin this paper. We also performed a broader disclosure via an industry forum.

196

message to the CAN data link layer, where various controland integrity fields are appended to generate a frame, whichis transmitted serially via the CAN physical layer. To receivea message, a recipient ECU’s data link layer interprets andvalidates the CAN frame prior to delivery of the message (IDand payload) to the application layer.

CAN bus is logical-ANDECU 1 ECU 2

0011 0101TX TX

ECU 1 0 0 1 1ECU 2 0 1 0 1

CAN Bus 0 0 0 1Fig. 2: CAN physical layer

The physical layer of the stack, i.e. the physical CANbus, consists of a broadcast communication medium betweenmultiple ECUs. The bus has two logical states: the dominant(logical-0) state, where the bus is driven by a voltage from thetransmitting ECU, and the recessive (logical-1) state, where thebus is passively set. The effective bus state is the logical-ANDof all transmitting ECUs’ outputs as illustrated in Fig. 2. ECUsconnected to the CAN bus communicate at a pre-determinedbus speed set by design based on the physical limitations ofthe bus. The length of each bit is directly determined by theset speed. For example, an ECU communicating at 500Kbpstransmits the dominant signal for 2µs to assert a logical-0.Similar to other asynchronous protocols (e.g. Ethernet), CANnodes rely on frame delimiters for interpreting the start andstop of CAN frames. Each ECU (re)synchronizes its internalclock based on observed transitions on the bus.

SOF

ArbitrationField Control Data CRC

ACK

EOF

IFS

ECUs transmit and simultaneously monitor bus state

Other ECUs respond;bus winner monitors

Bus winner completes

Sole bus winner transmits and monitors for bit error

Fig. 3: CAN frame format

The CAN data frame illustrated in Fig. 3 has four logicalsections: (1) arbitration, (2) data transmission, (3) acknowl-edgement (ACK), and (4) end-of-frame (EOF) and inter-framespacing (IFS). Upon detection of an idle bus, an ECU initiatesthe frame transmission with a dominant start-of-frame (SOF)bit followed by the arbitration ID. Due to CAN’s asynchronousnature, multiple ECUs may begin transmission at the sametime. While transmitting the ID, an ECU monitors the busstate and stops transmitting if it observes a bit different fromthe one transmitted. A received dominant bit during a recessivetransmission by a node indicates the transmission of a higher-priority message by a different ECU. By the end of arbitration,

a single ECU with the highest-priority frame wins access tothe bus and continues transmitting. The bus winner transmitsthe rest of its frame and, for each transmitted bit, monitors thatthe bus state matches the transmitted bit. During the ACK slot,the transmitter asserts a recessive bit while all receiving ECUstransmit a dominant bit to indicate correct reception. Finally,the sender transmits recessive EOF and IFS bits, where theIFS is the minimum space between two frames on the bus.After the IFS, the bus is idle and holds a recessive state untilthe next transmission. Each ECU can transmit multiple IDs,but each ID should only originate from a single ECU.

Error-Active Error-Passive

Bus-Off

Error Count > 127

Error Count ≤ 127 Error Count> 255

ECU RESET(automaticor manual)

Fig. 4: Three states of error-handling mechanism

Error handling and bus-off state: Error handling is anessential feature of the CAN protocol, providing robustness inautomotive environments. The CAN protocol defines severaltypes of errors; we detail two relevant error types, namelythe bit error and stuff error. A bit error occurs when thetransmitting node detects a mismatch between a transmittedbit and the bus state (outside of the arbitration and ACKfields). A stuff error occurs in the absence of a stuff bit,which is a bit of opposite polarity intentionally added afterevery five consecutive bits of the same polarity. When an ECUdetects an error, it transmits a 6-bit error flag on the bus thatcan destroy the contents of the current frame. Depending onthe error state of the ECU, the flag may be a sequence ofrecessive or dominant bits. Each ECU maintains error countersthat are incremented upon a transmission error3 detection anddecremented upon a successful transmission. As depicted inFig. 4, there are three error states based on the error count:(1) error-active, (2) error-passive, and (3) bus-off. An ECU inerror-active state represents a “low” error count and transmitsa 6-bit active (dominant) error flag; an ECU in error-passiveindicates a “high” error count and transmits a 6-bit passive(recessive) error flag. If enough errors are detected and thecount surpasses 255, then an ECU transitions to bus-off, whereit will shut down its CAN operations and effectively removeitself from the bus.

B. Shutdown via errors

While a large error count in a non-adversarial scenariois indicative of a faulty node and, hence, isolation (or evenshutdown) is a logical solution to prevent disruption of thewhole network, an adversary can misuse the error mechanism

3There is a separate count for reception errors, but it is not relevant to thiswork. All references to error count refer to the transmission error count.

197

by causing intentional errors, forcing an ECU to transitioninto the bus-off state and thus causing the ECU to shut downCAN communication. However, producing intentional errorson the CAN bus without direct access to the physical mediumis challenging. One reason is the compliance to the CANprotocol enforced by hardware CAN controllers designed andcertified for robustness. Thus, without access to the physicalmedium, an adversary can only control the ID and payloadbut not the transmitted frame. Nevertheless, recent works (assummarized in Table I) demonstrate limited success operatingunder these constraints to cause a shutdown.Errors via physical access: An adversary with physical accesscan easily bypass the CAN data link layer and inject bits byeither sending signals directly to the physical bus or modifyingthe CAN controller to disobey the protocol. An adversary canalso use this access to directly inject dominant bits at any timeduring a victim’s transmission and cause bit errors. Severalworks [5], [6] use this approach to demonstrate effectiveshutdown attacks that are difficult to detect as such errors areindistinguishable from genuine bus faults. These attacks havereal-time feedback from the bus, enabling a reliable methodof shutdown. However, because they require physical access,they are considered impractical both in research and practiceas there are easier alternatives to cause harm [12].Errors via remote access: Prior work [15] demonstratedthe ability to overwrite messages and exploit CAN’s error-handling mechanism without physical access. Here, an ad-versary must estimate a victim’s message transmission time.As most CAN messages theoretically tend to be periodic, anadversary could perform this attack via empirical analysis.Using these estimates, a remote adversary in control of theMCU’s software can transmit an attack message at the sametime and with the same arbitration ID as the victim. Thisapproach results in two nodes winning control of the busand intentionally violates the CAN bus protocol. A specially-crafted payload (a dominant bit in place of a victim’s recessivebit) can cause the victim to detect a bit error and retransmitits message; by repeating this attack, the victim eventuallyshuts down. Recent work [21] demonstrates that this attackis not reliable as the deviation of periodic messages variessignificantly in practice.Alternative shutdown mechanisms: While abuse of errors isone method to shut down an ECU, there are other means toshut down ECUs outside the protocol. One method, originallyintended for a mechanic to perform ECU testing, exploits diag-nostic messages reliably transmitted by a remote adversary [4],[18], [19]. However, such messages use known arbitration IDsand are easily detectable by automotive defense methods.

III. ATTACK OVERVIEW

A. Adversary model

For our attacks, we consider a remote adversary that isable to compromise an in-vehicle CAN node capable of trans-mitting messages on the bus via the CAN stack. As marketresearch estimates that about 150 to 250 million connectedcars will be on the road in 2020 [22]–[24], a remote adversary

will likely target the infotainment ECU or other ECUs in thevehicle with one or more remote interfaces [25]. We followthe same assumptions of prior work [10], [11], [15], [16],which assume that the adversary can modify the applicationsoftware on an ECU’s MCU and utilize any interfaces or APIsavailable to this software. However, we assume the adversarialcapabilities are limited to only software manipulation and donot allow for direct physical modifications or probing to anyof the vehicle’s components; in this work, our targets areunaltered modern passenger vehicles with only original ECUs.

Several prior and recent works [3], [4], [26]–[28] demon-strate the real existence of vulnerabilities to remotely com-promise in-vehicle ECUs and gain the ability to take controlof physical vehicle functions via CAN transmissions. Theseworks also demonstrate that remote attacks can occur at a largescale since a single vulnerability can be present across hun-dreds of thousands of vehicles [4]. These real-world demon-strations show that a remote adversary can exploit remotewireless interfaces to modify and/or inject code into softwarerunning on a vehicle’s MCUs. As outlined in two U.S. agencyreports [12], [29], a remote adversary is considered the highestrisk factor for the automotive community and passenger safety.Security efforts by vehicle manufacturers, e.g. introductionof IDSes, place significant focus on defending after such anadversary breaches the network [12]. For the remainder ofthis paper, when we describe the remote adversary, we useAPI and application-layer control interchangeably to refer tothe software instructions that the adversary can control.Attack goals: In general, a remote adversary will likely targetnon-safety-critical ECUs (e.g. the head unit or navigationsystem), which often have remote wireless interfaces to handlemultiple high-performance functions. As this adversary likelycannot gain direct compromise of a safety-critical ECU, theadversary will aim to utilize a compromised ECU to influencethe functionality of a different (typically safety-critical) ECUin the vehicle without being detected by any deployed networksecurity mechanisms, e.g. IDSes. One way to achieve thisattack using the compromised ECU is to shut down a criticalECU and then disable its functions or impersonate it after theshutdown. In this work, we focus on achieving a shutdownof a critical ECU without being detected by state-of-the-artnetwork defenses, i.e. the adversary succeeds if the defensecannot detect an attack prior to the shutdown event. As wewill demonstrate, the ability to reliably inject an arbitrary bitat an arbitrary time without being detected by vehicle defensesis sufficient to achieve these goals.

Thus, we effectively explore the possibility to construct areliable remote bit insertion attack, which aims to shut downan ECU, operates as a software application, does not requireaccess or changes to the physical CAN hardware, and deceiveseven state-of-the-art defenses. Furthermore, although severalattacks outlined in Sec. II-B achieve similar goals, to thebest of our knowledge, existing shutdown mechanisms cannotsimultaneously be remote (performed only at the applicationlayer), reliable (ability to consistently succeed), and stealthy(ability to deceive known defenses). The CANnon attack shows

198

that the adversary model used by the industry has changedand that the attacker now has new capabilities that priordefenses did not consider. The notion of stealth is difficultto characterize, considering the rapid progress in defensemechanisms. For this work, we consider the best-known resultsfor defense as described in Sec. VII.

B. High-level attack insight

Contrast with prior invasive glitch attacks: Creating artifi-cial clock glitches is a common technique to bypass securityof MCUs during boot or verification [19] by invasively drivingthe clock signal line to ground. The idea behind such atechnique is to create artificial transitions in the state machinesimplemented in hardware. As described in Sec. II-B, thedifficulty in injecting arbitrary bits is the CAN protocol en-forcement by the CAN data link layer, i.e. the CAN controller.Thus, similar to the security logic above, the controller canbe viewed as a hardware-based state machine that enforcesCAN protocol compliance. Thus, we draw inspiration from thesame direction of work but without requiring invasive physicalaccess to the clock.CANnon attack anatomy: Any finite-state machine (FSM),e.g. the CAN protocol, implemented using sequential logicelements (flip-flops, registers, etc.) relies on the clock signalfor state transitions and thus any output transmissions. There-fore, control of the clock signal can be used to force arbitrarydeviations from the protocol. As an example, small changesin clock frequency would directly result in a change of the bitduration on the CAN bus.

Automotive MCU

CANTXDATACPU +

MemoryCAN

Peripheral CANRXCAN

TransceiverCAN bus

OscillatorClock

Clock

Power

CAN HardwareSW App.

Fig. 5: Modern ECU design includes CAN peripheral thatruns off gated clock signal from MCU’s oscillator

Clock control is now possible: In an ideal design, theclock signal should not be accessible by a remote adversary.However, for modern ECUs, the MCU is a multi-chip mod-ule, where the CAN controller is integrated into the samepackage as the MCU and is now called a CAN peripheral.A simplified example of the modern ECU architecture isshown in Fig. 5. Additionally, most modern MCU architecturesimplement power optimization in the form of peripheral clockgating. This low-power feature saves energy by shutting downany unwanted peripherals when they are not required, whileallowing the main CPU and other critical functions in theMCU to still operate. As the CAN controller is typicallyattached as a peripheral to the MCU chip, there are controlsexposed to cut off the CAN peripheral’s clock.

To allow flexibility and control to low-level system design-ers, most MCUs provide the system designer a small software

interface for the controls that allow clock cut-off. As demon-strated in Sec. VI, clock control can be arbitrarily exercisedduring regular operations, which can also provide a remoteadversary in control of the software with the same ability tocontrol the CAN protocol FSM. This control effectively allowsan adversary to gate the clock and freeze the protocol FSM,only to later restart the clock to resume the FSM. Thus, thisnew capability allows an adversary to arbitrarily manipulatethe CAN protocol without modifying the hardware.

We note that, in most scenarios, cutting off the clock doesnot affect any data present in the sequential elements or theoutputs of the logic gates. It simply prevents a change in thestate of these elements. Also, without architectural changes,the notion of a frozen state or disabled clock cannot berecognized or corrected by the CAN controller. An alternativecontrol in the form of power gating may also be available incertain chips, and we investigated exploiting such mechanisms.However, we find that disrupting the power simply resets theperipheral and its buffers/registers, causing the CAN FSMand output to be reset. Ultimately, we discover this attackvector in the driver code for the CAN peripheral. In hindsight,we realize that another factor that enabled our discoveryof this vulnerability was our choice in experimental setup(detailed in Sec. VI), which closely resembles the modernMCU architecture, whereas most prior research has continuedto use the legacy architecture.

C. Overview of the attack

For any transmission, the CAN controller outputs the bitsof the frame serially onto the transmit output pin (CANTX inFig. 5), where each new bit is triggered by a clock transition.The binary output of the controller is converted to a CAN-compatible analog value on the bus by the transceiver.

Consider the case when the CAN controller is transmittinga dominant logical-0 bit. If the clock is disabled (paused)before the next bit, the CANTX output would continue tobe logical-0 until the next clock edge. Thus, the node wouldcontinue to assert a dominant signal until the clock signal isresumed. This action effectively allows the transmission of adominant bit of arbitrary duration. Now consider the oppositecase when the CAN controller is transmitting a recessivelogical-1 bit. If the clock is disabled, it would continue toassert a recessive value on the bus, i.e. no signal. The rest ofthe payload resumes transmission only when the clock signalis resumed. This action allows the transmission of the payloadat an arbitrary time. Observe that the adversary exploits thecontroller’s inability to sense the bus state when its clock is inthe paused state. Thus, resuming the clock resumes the FSMfrom the point it was stopped, regardless of the current busstate or the controller’s transmission output on the bus. Thisfact is key to disable the back-off arbitration control in CANcontrollers and to transmit a signal at an arbitrary time.

IV. BASIC REMOTE DISRUPTION ATTACK

In what follows, we take a step-wise approach to increasethe sophistication of our attack, ultimately demonstrating a

199

controlled victim shutdown. In this section, we begin witha simple application of clock control to disrupt the entirenetwork via a denial-of-service (DoS) attack. This basicdisruption also highlights practical constraints that we mustconsider to design a reliable attack strategy. We note that thisbasic attack is easy to detect, and current hardware measurescan sufficiently protect against it. However, the techniqueswe describe are the basis for precise and consecutive errorinjections required for the targeted shutdown attack in Sec. V.Clock gating at application layer: The primary requirementfor this attack is that the MCU must have control over theclock input for its peripherals, e.g. controllers for differentprotocols, such as CAN, Ethernet, FlexRay, etc. For the attackwe present here, we choose a popular hardware device witha high-performance MCU built for networking applications:the Arduino Due board with an AT91SAM3X8EA 32-bitMCU operating at 84 MHz [30]. The Arduino Due offersmany networking peripherals (e.g. CAN) and its source code(and CAN drivers) are well-documented, making it idealfor demonstrating our insights. In fact, we find that MCUsmarketed as “high-performance” often include peripheral clockgating as a low-power feature available for the system designer(and thus a remote adversary).

Another requirement is that enabling/disabling the clocksignal should not reset the peripheral circuitry or change valuesof its logic elements. Ideally, disabling the clock should onlyprevent the sequential elements from transitioning to a newstate. This fact holds true for basic clock control mechanisms.For the APIs of the automotive MCUs we evaluate in Sec. VI,we find the presence of multiple instructions that controlthe clock. Typically, for some of the commonly used APIs,MCU designers may implement additional check routinesbefore/after a clock disable instruction to ensure error-freefunctioning, e.g. check status of transmission, etc. However,these procedures were only implemented for some of theavailable clock control instructions, and we find at least oneinstruction that offers a basic control mechanism.

To use the clock control, the adversary must identifywhich instructions enable an MCU’s application to con-trol peripheral clock signals. Typically, manufacturers pro-vide basic driver code for initialization of several periph-erals as part of their software development kit (SDK). Insuch cases, we can discover clock control instructions inthe drivers for the CAN peripheral. Alternatively, in theevent that all clock control instructions are not completelydetailed, the reference/programming manuals for a given MCUoften outline the steps required to control the peripheralclock and will provide the specific registers that control theclock gating. In the driver for the Arduino Due, we dis-cover the instructions, pmc_enable_periph_clk() andpmc_disable_periph_clk(), to enable and disable theclock, respectively. These instructions appear prior to low-level configurations, e.g. memory allocation, buffer flushes,etc. However, for another MCU popular in the automotivecommunity, the STMicro SPC58, finding equivalent clock con-trol instructions was more challenging as directly disabling the

peripheral clock was not possible. Thus, we use its referencemanual to identify specific registers that grants us a similarclock control capability in Sec. VI.Simple disruption attack: Recall that the CAN bus state isdominant if at least one ECU transmits a dominant bit. Asa CAN frame consists of a series of dominant and recessivebits that follow a particular format, no valid information isconveyed from a single state held on the bus. Additionally,such a condition would result in continuous errors in the ECUsdue to absence of stuff bits.

Thus, a basic attack we conceive is to disrupt the bus byholding the bus in the dominant state. This disruption wouldprevent any other ECU from transmitting, leading to a DoSof all ECUs in the network. An adversary could perform thisaction at a critical time (e.g. while the vehicle is in motion)and disrupt key vehicle functionality. For most vehicles, thisattack would result in loss of control by the driver.

1 0 1 0 1 0 0 0 1 0 1 0 0 0 0 0 0 0 0 0Actual attack output

Logical attack output

1 0 1 0 1 0 0 0 1 0 1 0 1 1 1 0 1 1 1 0

Remote adversary disables clock

Dominant state held

Fig. 6: Holding dominant state disrupts the bus

Using clock control instructions, the adversary could easilyachieve this attack by disabling the clock and freezing the CANcontroller state when it transmits a dominant bit. To launch thisattack, a basic method is to target the start-of-frame (SOF) bit:

• Send a message transmission request to the CAN periph-eral with any priority and payload.

• Use a timer to delay for half a bit length for the givenbus speed so the peripheral starts the transmission of theSOF bit.

• Pause the clock using the disable command to freeze thestate of the CAN controller during the SOF bit.

If the bus was initially idle, this sequence would likely leadto the node continuing to hold the dominant state as depicted inFig. 6. However, there are several practical challenges evidentfrom these basic steps. One critical challenge we encounteris the precise timing required to freeze the controller duringthe target SOF bit. In practice, the selected delay value onlyworks if the bus was idle when the transmission request wassent and the frame immediately transmitted. In a real scenario,the transmission may start much later, e.g. other bus traffic,scheduling delay, etc. Even minor variations in the timer usedto realize the delay period can cause an adversary to missthe SOF bit. Furthermore, any variation in the latency of theactual clock gating effect from the time that the instructionwas issued can cause an adversary to miss the SOF bit.

Although there are practical constraints in this attack, thesimplicity of this attack (as a result of our attack insight)affords an adversary a great deal of flexibility. For example,

200

missing the SOF bit could be compensated for by using an IDof 0x0 and data payload of 0x0 (essentially a message of allzeros). Thus, freezing the controller during the arbitration ordata payload field would also disrupt the bus. However, eventhis all-zero message has recessive bits due to bit stuffing whenconverted to a CAN frame. Thus, accidentally encounteringthose bits due to unreliable timing can cause the attack to fail.

This disruption attack is easy to prevent (if not alreadyprevented) by most modern CAN buses. This disruption attackclosely resembles a typical hardware fault encountered in areal CAN bus, i.e. bus held-dominant faults. Thus, severalexisting CAN transceivers implement built-in mechanisms toprevent the bus from holding a dominant state for a long periodof time. This attack demonstrates the practical feasibility ofusing the clock control to launch an attack. This attack, thoughpotentially dangerous, is highly obstructive for all nodes. It isstill short of the goal of this work, which is to target a singleECU with high reliability and without being detected.

V. RELIABLE TARGET VICTIM SHUTDOWN

In this section, we address some of the limitations discussedin the previous section to achieve a reliable attack thatcan target a specific victim ECU and quickly shut it down.We detail three variants of the CANnon attack and providesolutions to challenges observed in practical scenarios.

A. Reliable clock control

In Sec. IV, we illustrated the difficulty to ensure the clockis paused during a dominant bit. In general, an adversary withunreliable control of the clock cannot precisely ensure whatstate the controller outputs. Also, unlike the previous attack,a targeted attack usually requires overwriting specific bits ofa victim message, thus requiring even more precision. Onesource of this unreliability is the variation in latency of theclock gating instructions, before the clock is actually paused.Another issue for this attack is that the adversary must trackthe state of the CAN bus and its own transmissions in order totarget specific bits. However, when the CAN controller is inthe frozen state, it does not have the ability to observe the CANbus state. Without feedback, the adversary is virtually blind tothe actual peripheral output while performing an attack. Thus,the adversary must keep track of which bit of a compromisedECU’s frame it is transmitting at all times.

When the adversary calls a clock gating instruction (eitherenable or disable), we experimentally find that it takes upto two MCU clock cycles for the instruction to resume theperipheral’s output. Thus, the adversary cannot reliably gatethe clock near the edge of a bit transition of the attack message.A nonzero latency means that the adversary cannot ensurewhether a gating instruction results in the output of the statebefore or after the state (bit) transition. This latency can thusinfluence the state of the bus that is held when the controller isfrozen. Additionally, an adversary will need to make repeatedcalls to gating instructions within a single frame transmissionby the compromised ECU. If the adversary loses precision in

their clock control at any time, they could lose track of whichbit the compromised ECU is currently transmitting.Improving precision: To address the challenge of reliableclock control, the adversary can take advantage of the fact thatthe MCU’s clock operates at a much higher frequency than theCAN peripheral’s clock. We utilize the MCU’s hardware-basedtimer, operating it at a frequency equal to the bus speed. Thistimer creates interrupts at the middle of each CAN bit, whichallows us to track exactly which bit the compromised ECU istransmitting. Prior to starting the timer, the adversary must firstdetect when the compromised ECU attempts to send a frame;from this point, the adversary should delay half of a bit timebefore starting the timer interrupt. Our solution is to gate theclock as close to the middle of a CAN bit, giving the adversarymaximum distance from bit transition edges. With an interruptat the middle of each bit, the adversary can reliably track thebus state and control the clock with bit-level precision.

B. Insertion of a single bit

The precise clock control described so far can be used toinsert a single bit on the bus. As described in the previoussection, simply disabling the clock is not sufficient for theadversary to relinquish bus control. It must be ensured thatthe clock is disabled during a recessive transmission so thatthe adversary can continue its attack at a later time (recallthat a recessive output does not influence the bus). Sincethe adversary only has clock control at the middle of a bit,the following steps are required to inject a single dominantbit, assuming the compromised ECU is currently paused atthe recessive state: (1) enable clock a half-bit time beforerecessive-to-dominant edge, (2) wait one bit time to enterdominant bit, (3) wait another bit time to enter recessive bit,and (4) pause clock a half bit-time after dominant-to-recessiveedge. Thus, the adversary must use such a pattern of bits withinits payload, i.e. a dominant bit between two recessive bits.

However, this attack pattern introduces another unique chal-lenge. As described earlier, the ECU reads bus state aftereach transition. Thus, if the adversary stops its attack duringa dominant transmission by the victim, the compromisedECU will raise an error since it transmitted a recessive bit(a stopping requirement for the adversary) but observed adominant transmission. This error will cause the attack ECUto reset its transmission so we must investigate methods toovercome this challenge as discussed below.

C. Causing an error on the victim

We now discuss how to exploit clock gating to induce justa single error on a victim. Our goal is to trick the victiminto detecting an error in the transmission of its own frame,causing its transmit error counter to increase. To achieve this,the adversary must induce an error after the victim winsarbitration and becomes the sole transmitter. As detailed inSec. II, a node transmitting on the bus simultaneously checksthe bus for any bit errors. Thus, the adversary can simplyoverwrite a victim’s recessive bit with a dominant bit using thesteps outlined in the previous section, tricking the victim into

201

thinking it caused the error. To successfully achieve this, thereare two practical challenges that the adversary must consider:(1) it must account for the victim response, i.e. error flagtransmission, and (2) it should identify bits in the victim framethat can be reliably targeted.Victim’s error response: When the adversary overwrites avictim’s recessive bit with a dominant bit, the victim willdetect a bit error and immediately transmit an error frame.Depending on the state of the victim’s error counter, thiserror frame can be a series of six dominant or recessive bits.However, as outlined in Sec. V-B, an adversary cannot stopits attack during a victim’s dominant transmission. Thus, anadversary cannot stop the attack if it expects the victim totransmit an active (dominant) error flag.

1 0 0 0 0 0 0 1Actual

attacker output

ISR will either:A. Enable clockB. Disable clockC. Do nothing

Timer ISRInterrupts every CAN

bit time

A B C C C C A B

Fig. 7: Use timer ISR to convert a single logical-0 bit to a6-bit error frame

To resolve this, the adversary can exploit their clock controlto expand a single dominant bit into a series of six additionaldominant bits, or an active-error flag. To generate an active-error flag from a single dominant bit, we perform four stepsas depicted in Fig. 7:

1) With clock paused on a recessive bit, the adversaryresumes clock for one bit time (or until the next timerinterrupt).

2) After the recessive-to-dominant edge, the adversarypauses clock so the compromised ECU holds dominantstate.

3) After five timer interrupts, the adversary resumes clock.4) The compromised ECU’s output transitions from domi-

nant to recessive, and the adversary pauses the clock atthe next interrupt and is ready for the next attack.

By simultaneously transmitting the flag as the victim trans-mits its flag, both flags will overlap, and the compromisedECU’s transition from dominant to recessive will occur whenthe bus state is recessive due to the recessive end of theerror flag. This approach enables the attacker to maintain anerror-free transmit state on the compromised ECU so it mayprepare for the next error injection. In scenarios where thereare multiple nodes on the bus, the length of the error framemay be longer and thus the dominant duration by the attackershould be adjusted accordingly.Targeting victim frames: A challenge we face is determiningwhich bit to overwrite during a victim frame. Assuming thatthe adversary can determine the starting point of the victim’stransmission, identifying the location of general recessive bitsmay be difficult due to variations in the payload and stuff bits.Recall that, during the paused clock state, an attacker has no

source of feedback from the bus. Thus, we must identify someinvariant about the victim’s transmission for the adversary toexploit. We borrow an insight from prior work [15] to targetthe control fields, which often are static as data payloads donot change length. Alternatively, the adversary could analyzeseveral frames prior to attack and target bits in the data payloadthat remain static. However, as the stuff bits can vary, it ispreferable to use the initial control bits for attack.

D. Shutting down victims with CANnonWe now stitch together the components described above

to transition a victim into the bus-off state. To achieve theshutdown attack against a specific victim ECU, the adversarymust cause enough errors to forcibly transition the victim intoa bus-off state. The goal here is to produce an attack thatoperates as fast as possible. For now, we assume that victimtransmissions are periodic, which is often the case according toprior work [21], and thus the period can be used to estimatea victim ECU’s SOF bit transmission time. As depicted inFig. 8, the CANnon attack consists of two phases: a loadingphase, where the attacker prepares the attack, and a firingphase, where the error frames are generated.

Load attack

frame into TX buffer

Phase 1:LoadingCANnon

Phase 2:Firing

CANnon x32

Wait for IFS to get

bus access

Transmit arb. + ctrl. field and

wait

Wait for target

message

Transitionto

dominantbit

Disable clock for

6 bits

Transitionto

recessivebit

SOF

Arb. + Ctrl.ID = 0x000

Data Payload0x5555.5555.5555.5555(Alternating 0’s and 1’s)

CRC Field

ACK

EOF

IFS

Fig. 8: Two-part approach to the CANnon attack

Loading the CANnon: To be able to transmit any arbitrarysignal on the bus, the CAN controller must first win arbitration.Since the adversary only controls the software and is unableto modify the CAN controller, the compromised ECU’s FSMshould be in the same state (sole arbitration winner) before theadversary can attempt to transmit arbitrary bits. Thus, in theloading phase, the adversary aims to trick the compromisedECU into thinking that it is allowed to transmit on the busas preparation for the firing phase. To do this, the adversaryloads the attack frame (of a specially selected ID and payload)into the CAN peripheral’s transmit buffer and waits for thecompromised ECU to win the bus. In this attack, the adversarywaits for completion of the arbitration phase and transmissionof the control bits, before pausing the clock during the firstpayload bit, which can be designed to be recessive. At thispoint, the adversary is ready to start the firing phase of theattack while waiting for victim messages to appear on the bus.

To ensure a quick transition into the firing phase, theadversary can set the arbitration ID of the attack frame to 0x0,

202

giving it highest priority on the bus. This ID ensures that thecompromised ECU wins control of the bus as soon as the busis idle. Then, to transition a victim into bus-off, the adversaryneeds to inject a dominant bit 32 times using a single attackframe. Thus, the data payload should be set to contain 64 bitsof data with a pattern of alternating 0’s and 1’s, or a payloadof 0x5555.5555.5555.5555. This payload gives the adversary32 dominant bits to use for an attack and 32 recessive bits totemporarily pause the attack between victim transmissions. Anadditional benefit is that having a consistent pattern simplifiesthe logic for the adversary.

It should be noted that a different attack payload can stillbe utilized to achieve the same attack, albeit in a slightly sub-optimal manner. Any deviation from a payload of alternatingdominant and recessive bits would require the attacker toreload another attack frame before shutting down the ECU.Firing the CANnon: In the firing phase, the adversary utilizesthe strategy described earlier to convert a single dominant bitinto an active error flag, which will overwrite the recessive bitsof the victim message. The adversary must wait for a victimmessage to appear on the network by waiting for its nextperiodic transmission that wins bus arbitration. The adversarythen overwrites its selected recessive bit, causing the victimto detect an error and increment its error counter by 8. Afterdetection of the error, the victim will immediately attempt toretransmit the failed frame. The adversary repeats this firingphase against 31 back-to-back victim retransmissions untilthe victim’s error count reaches 256 (8x32) and enters thebus-off state. Thus, after the adversary causes an error inthe first victim transmissions (using its period), targeting theretransmissions is significantly easier for the adversary.

E. Alternative CANnon implementations

Although the strategy described above is an efficient methodto force the compromised CAN controller to transmit, wealso describe alternative methods that achieve a shutdownattack using different parts of the CAN frame to highlightthe flexibility an adversary has for the CANnon attack.Firing with SOF bit: Instead of the above two-phase ap-proach, imagine if the adversary could just skip to the firingphase. Our insight here is to use the SOF bit but with adifferent approach from Sec. IV. By stopping the clock rightbefore a SOF transmission, the adversary can inject a dominantSOF bit during a victim’s recessive bit. Since the SOF isonly transmitted after a bus idle, the adversary can onlytransmit a SOF when it knows the bus is idle. Once busidle is detected, the compromised CAN controller will loadthe registers to prepare for frame transmission. The adversarycan pause the clock right when the transmit registers areloaded (experimentally, we find this to be two CAN bit times),effectively stopping the transmitter before it sends a SOF.

However, as the SOF is only a single bit, the error active flagfrom the victim will cause an error on the compromised ECU,forcing it to retransmit. Instead of avoiding this retransmission,the adversary can exploit it. The victim’s error flag will causethe compromised ECU to think it simply lost arbitration.

The adversary can then wait for a bus idle to occur andperform its attack again. Bus idle will not be observed untilafter the victim successfully retransmits so the adversary willneed to target the periodic victim transmissions instead ofits retransmissions from the loading/firing attack. While thisattack is not as fast as the loading/firing attack, it doesenable the CANnon attack on alternative MCU architecturesas explained in Sec. VI.Firing with ACKs: Instead of using data frame transmissionsto attack a victim ECU, the adversary could exploit anotherscenario where the compromised ECU transmits a dominantbit: the acknowledgement (ACK) slot. To acknowledge acorrectly received data frame, an ECU will set a dominantbit during the ACK slot of the data frame. Our idea here isthe adversary could pause the compromised ECU right beforeit transmits the ACK bit for a victim’s frame (the bit beforethe ACK slot is a recessive CRC delimiter bit). Suppose theCAN peripheral offers a SOF bit interrupt, which we observein a number of automotive MCUs [30], [31]. If the adversaryknows when the victim frame transmission starts and candetermine when the CRC delimiter bit occurs in the frame,the adversary can pause the clock before the ACK slot andresume the clock just a few bit times later during the EOF,causing an error on the victim. The challenge here is that theadversary must precisely predict when an ACK will occur andthe number of bits in the victim frame. Thus, victim framesthat contain static or predictable data make an ideal target.

F. Practical challenges

We now discuss approaches to solving two practical chal-lenges we encounter when launching CANnon against realvehicles in Sec. VI, one of which is a new capability resultingfrom the peripheral clock gating vulnerability.Period deviations in victim frames: Up to now, we make theassumption that victim frame transmissions will be periodic.However, in practice, prior work [21] has found that perioddeviation is nonzero, which makes it difficult for the adversaryto predict victim transmission times and thus perform theshutdown attack. Using insights from prior work [15], wecould estimate when a victim message will initially appearon the bus. However, these insights relied on other messagesin the network that would transmit immediately before thevictim message, which is not always guaranteed. Likewise,even considering these circumstances, this approach has beenfound to not be reliable [21].

We introduce a new capability that permits an adversaryto guarantee when a victim message appears on the CANbus. We first revisit an observation made in Sec. IV duringtests on real vehicles. When the compromised ECU holds adominant state, all other ECUs will queue their frames waitingto transmit during bus idle. Upon releasing this dominant state,all transmitting ECUs will attempt to clear their queues. Wefind that these queued frames appear on the bus in a pre-defined order: by their arbitration ID. Our insight here is todetermine which messages should arrive in a given range oftime prior to launching our attack. By holding the dominant

203

state for this range of time,4 we can predict the ordering ofmessages and thus predict the start of the victim transmission.Interruptions by higher-priority messages: Another practi-cal challenge we encounter when launching CANnon againstreal vehicles is that higher-priority messages can interrupt theattack. If the adversary targets a victim frame with a lowpriority, we find that higher-priority messages can interruptthe repeated retransmissions by the victim. As the adversaryexpects the victim retransmissions to occur back-to-back, theseinterruptions can cause the attack to fail by causing collateraldamage against unintended victims. Thus, the adversary coulduse prior work [21] to identify all source IDs of a victim ECUand simply select the highest-priority message, minimizing thechance of interruption by a higher-priority message. Addition-ally, prior work [21] also finds that safety-critical ECUs tendto transmit higher-priority frames so our adversary is alreadyincentivized to target higher-priority frames.

VI. EVALUATION

In this section, we demonstrate CANnon using two auto-motive MCUs found in modern vehicles and launch shutdownattacks against a variety of targets, including two real vehicles.We also detail experiments to highlight the reliability andstealth of CANnon.

A. Experimental setup

To demonstrate the significance of this attack, we launchCANnon from automotive MCUs used by modern vehicles, andwe target real ECUs from two real vehicles. In this work, wedo not explicitly show the ability to compromise an in-vehicleECU remotely as this has been the focus of a large number ofpapers [3], [4], [26]–[28]. Rather, we build our attack on theassumption that these existing techniques would be successfulin remotely compromising the software of automotive ECUs.

One of the key factors that enabled the discovery of thisvulnerability was our choice of experimental setup, which islikely why, to the best of our knowledge, this incidence has notbeen studied before. In this work, we initially used the ArduinoDue board, which closely resembles the capabilities of modernautomotive MCUs. However, if we look at prior work in thefield [6], [10], [11], [15]–[17], [32], [33], we find widespreaduse of the legacy design of automotive ECUs, namely anArduino Uno board with a standalone controller. Thus, as aresult of our choice of experimental setup, none of these priorworks could have identified the CANnon vulnerability; wherethe industry moved to a modern design, prior research hascontinued to use the legacy design.Automotive MCUs: In addition to the Arduino, we testCANnon on evaluation boards for two automotive MCUs fromMicrochip and STMicro (commonly known as ST). Theseboards will serve as the compromised in-vehicle ECUs as theyare used in modern production vehicles. In fact, STMicro isone of the top five semiconductor suppliers for the automotive

4Where prior work required injecting a message to guarantee transmissiontime of a victim, we can simply disrupt the bus to “simulate” an injectedmessage.

industry [34], and its MCUs are likely to be in many modernvehicles. The features and architectures they offer are likelygeneralizable to other automotive MCUs as they are bothmarketed as high-performance networking MCUs, which aretwo key features we identify in Sec. IV. While we do notevaluate boards from every MCU supplier, we find multiplereferences to software APIs for peripheral clock gating inreference manuals and market reports [35]–[39].

Specifically, we evaluate: (1) the Microchip SAM V71Xplained Ultra board, which uses an ATSAMV71Q21 32-bitMCU operating at 150 MHz and is designed for in-vehicleinfotainment connectivity [31], [40], and (2) the STMicroSPC58EC Discovery board, which uses an SPC58EC80E5 32-bit MCU operating at 180MHz and is designed for automotivegeneral-purpose applications [41], [42]. It is likely that otherMCUs in the same family (i.e. SAM V MCUs and ST SPC5MCUs) share the same peripheral clock gating vulnerabilityas demonstrated by similarities within an MCU family’sreference manuals [30], [31]. Consequently, the Arduino Dueboard identified in Sec. IV uses an AT91SAM3X8EA 32-bitMCU operating at 84 MHz from an older series of the sameSAM family [30].

For the SPC58 MCU, we encountered a challenge in findinga clock enable/disable function. All clock functions requestedthe peripheral to essentially give the MCU permission todisable the peripheral’s clock. Upon receiving the request,the peripheral waits for all transmission operations to stopbefore the MCU can disable its clock. However, we found analternative approach to directly control the clock on the SPC58that bypasses this request procedure. In fact, this alternativecontradicts the expected implementation as described in theSPC58’s reference manual [42]. The SPC58 utilizes operat-ing modes that change the configurations for the MCU. Inparticular, we focus on two modes: the DRUN mode, whichpermits all peripherals to run normally, and the SAFE mode,which stops the operation of all active peripherals. We findthat a transition to DRUN is equivalent to enabling the CANperipheral’s clock and a transition to SAFE effectively disablesthe peripheral’s clock without permission from the peripheralitself. A limitation introduced here is that a clock enable couldnot occur soon after a clock disable5, but the SOF-based attackfrom Sec. V successfully works for the SPC58.Real vehicle testbed: Additionally, we demonstrate CANnonagainst two real vehicles: a 2009 Toyota Prius and a 2017Ford Focus. We connect to the CAN bus by accessing the busvia the vehicle’s On-Board Diagnostics (OBD) port to emulatea remotely-compromised ECU. We also identify the mappingof arbitration IDs to source ECUs using details from priorwork [21]. We only launch the CANnon attack against vehicleswhile they are parked to avoid any potential safety concerns.Note that these vehicles have their engine running with allECUs actively transmitting onto the network. As detailed inprior work [21], vehicles tend to transmit mostly periodic

5The transition to SAFE mode (or effectively disabling the clock) includesseveral processes that must complete for safety reasons before the peripheralclocks can be enabled.

204

messages, and we find that these transmissions start when theengine is started. Even if the vehicle is taken on a drive, onlythe data payloads change rather than periodic transmissionrates. We also launch CANnon against an Arduino Due, aPeakCAN USB device, and a 2012 Ford Focus powertrainECU in a variety of synthetic network setups.

B. CANnon against real vehicles

Basic disruption on real vehicles: We launch the basicdisruption attack against both real vehicles using the SAMV71 and SPC58 evaluation boards. As discussed in Sec. IV,ECUs often implement a time-out feature that prevents a CANtransceiver from holding the dominant state for an extendedperiod of time. We experimentally find that we can maintainup to 1ms of dominant state on the bus with at least 4µsof recessive in-between on both vehicles. We find that thisattack prevents ECUs from communicating on the bus and willtrigger malfunction lights on the instrument panel and evendiagnostic codes that indicate loss of ECU communication.Powertrain ECU shutdown in 2017 Focus: We demonstratea shutdown attack with the V71 MCU using the loading/firingattack in Sec. V. The powertrain ECU transmits severalarbitration IDs, but we select the highest-priority ID usingmethods from prior work [21]. In our pre-analysis of thevictim transmission times, we find that a majority of thepowertrain ECU’s IDs will transmit back-to-back. With ourtechnique for guaranteeing transmission times in Sec. V, wehold the dominant bit when we expect the victim to appear(for approximately 50µs). Upon release of the dominant bit,the target victim frame will be the first frame to transmit and,thus, we launch our firing phase on that frame. We target thecontrol field and perform this attack 32 times, allowing us toshut down the powertrain ECU in about 2ms. Although thepowertrain ECU does auto-recover, the ability to shut downthe ECU quickly demonstrates the speed of our attack.Power steering ECU shutdown in 2009 Prius: We demon-strate a shutdown attack with the SPC58 MCU using theSOF-based attack in Sec. V as the SPC58 cannot enablethe clock immediately after disabling it. The target victimis a power steering ECU that transmits three IDs: 0x262,0x4C8, and 0x521. We choose the ID with the smallest period(0x262 with period of 20ms) and find that its period deviationis quite small using methods from prior work [21]. As theSOF approach requires a successful transmission between eachattack, this shutdown is significantly longer since we do nottarget retransmissions. We shut down the power steering ECUafter 700ms, and we find that it remains permanently offline.

C. Attack reliability

One important aspect of a reliable attack is repeatability.We envision an adversary who purchases the same MCU thatthe compromised ECU uses as preparation for their remoteexploit and shutdown attack. After tuning attack parameters tothe specific MCU (e.g. number of MCU cycles prior to SOFtransmission), the adversary hopes that the tuned parameterswill be similar to that of the real victim MCU. We find

that properly tuned attack code across multiple copies ofour test MCUs over a few months could repeatedly producethe same output to the bus. We attribute this success to thestrict specifications that ECU hardware must follow in themanufacturing stage.

We now compare the reliability of CANnon using thehardware timer interrupt centered on each CAN bit versusmanually counting MCU clock cycles. In this experiment, weuse the Microchip and Arduino Due boards to transmit activeerror frames at repeated intervals. We transmit these framesagainst an Arduino Due victim that sends its frames every10ms with zero deviation in the period. Using a hardwaretimer to launch our attack, we find that both the Microchipand Arduino Due boards can shut down the victim 100%of the time. However, if we try to perform the active frametransmissions by manually keeping count of MCU clockcycles, we only achieve the attack 10% of the time due tovariations discussed in Sec. V.

We also compare the reliability to guarantee victim trans-mission time versus prior work [15] that overwrites messagesusing injected messages to predict victim transmission. Here,we use the Arduino Due board to target three different victims:(1) another Arduino Due, (2) a PeakCAN device, and (3) a2012 Ford Focus powertrain ECU. Using our method, we canachieve a shutdown of all three victims using all three ofour MCUs 100% of the time. However, using prior work toperform the message overwrite attack, we only succeed for theArduino Due and PeakCAN device. On the powertrain ECU,we cannot achieve even a single success as its transmissionsexhibit significant period deviation.

D. Stealth analysis

We now compare the stealth of CANnon versus the state-of-the-art message overwrite attack [15]. We construct threesimple detection methods at each layer of the CAN stack basedon existing defenses.6 The goal of either shutdown attacker isto achieve a victim shutdown without the detection methodalerting prior to the shutdown itself. Our experimental setupinvolves three Arduino Due boards: (1) the victim ECU, (2) thedetection ECU, and (3) the compromised ECU. The detectionECU also transmits its own messages to simulate other trafficon the bus. We perform each test 1,000 times, and we operateall tests at 500Mbps, use a shared 12V supply to power theboards, and observe the bus traffic using a logic analyzer.

For all of the experiments below, we follow the configura-tion of prior work [15]: the victim ECU transmits ID 0x11every 10ms, the detection ECU transmits ID 0x7 and 0x9every 10ms, and the compromised ECU monitors the bus andattempts to attack. To simulate noise from a real vehicle, weintentionally set the deviation of ID 0x11 to 0.15ms as thebest-case minimum deviation found by prior work [21]. Forall experiments with the overwrite attack, the compromised

6We do not demonstrate CANnon against complete implementations ofexisting defenses, which monitor only entire CAN messages or frames, asthey are ineffective by construction as detailed in Sec. VII.

205

ECU injects ID 0x9 around the expected transmission time of0x11 to set up their attack.Versus timing-based IDS: We first test the overwrite attackand CANnon against a timing-based IDS that alerts if framestransmit outside of their expected period. Timing-based IDSesalso include ML-based [43] and traffic anomaly methods [44]as they analyze timestamps to detect illegitimate transmissions.We set the detection threshold for period deviation to be 10%(e.g. 1ms for a 10ms period) following prior work [9]. Weprogram our detection ECU to measure the inter-arrival timebetween frames for a given ID and alert if the measuredtime exceeds 10% of the expected period. For CANnon, thecompromised ECU attacks using the data payload and employsthe dominant-hold technique from Sec. V to guarantee victimtransmission time. Out of 1,000 attempts, we find that ourdetection ECU alerts to every attempt by the overwrite attackbut does not alert to any of the CANnon attacks. CANnon onlyneeds to hold the dominant state for 0.15ms once to guaranteethe first victim transmission and cause an error. The overwriteattack injects new messages onto the network, exceeding theexpected deviation threshold. CANnon achieves a shutdown injust 2ms before the next transmission should occur.7

Versus a “secure transceiver:” As secure transceivers arenot currently in production, we modify the detection ECUto act as the secure transceiver. It will read each logical bittransmitted and received by the compromised ECU by directlyconnecting between the MCU’s CAN peripheral and the CANtransceiver following prior work [21]. If an ECU sends anillegitimate arbitration ID, it will produce an alert in real-timeimmediately after the arbitration field transmits. For CANnon,the compromised ECU attacks via the SOF bit method as thesecure transceiver could detect the data payload attack.8 Outof 1,000 attempts, we find that our secure transceiver alertsto every attempt by the overwrite attack but does not alert toany of the CANnon attacks. CANnon only injects a SOF bitas its attack and does not transmit any arbitration ID, whilethe additional message transmissions in the overwrite attackcause our secure transceiver to alert immediately.Versus a frame-level voltage IDS: Following observationsfrom prior work [10], [11], [45], we modify the detectionECU to directly measure the CAN bus voltages to detect anattack. The CAN medium is a differential pair called CANlow and CAN high that typically exhibit around 1.5 and 3.5voltages for a dominant bit, respectively (recessive state causesboth to exhibit 2.5 volts). The key insight from prior work isto measure the voltage of the dominant bits throughout anentire frame. With the message overwrite attack [15], the startof an overwritten frame has two transmitters and ends witha single transmitter, i.e. the compromised ECU. Thus, theattack exhibits a larger differential at the start and a smallerdifferential at the end of an overwritten frame. We build a

7This fast ability to shutdown could act as a useful stepping-stone to futurework on masquerade attacks.

8CANnon could technically use any arbitration ID (even a legitimate ID),but we assume that the adversary wants to use ID 0x0 to minimize wait forbus idle.

voltage IDS that alerts if the dominant bits exhibit a suddendrop in dominant differential voltage during a single frame.Out of 1,000 attempts, we find that our IDS alerts to everyattempt by the overwrite attack but does not alert to any ofthe CANnon attacks. CANnon only injects a single error flagin the middle of a frame and, thus, this approach to voltageIDS does not detect our attack.

VII. STEALTH AGAINST NETWORK DEFENSES

Next, we discuss why CANnon evades state-of-art defensesand also how to tackle future CANnon-aware defenses.

A. Deceiving state-of-the-art defenses

Many approaches exist that can defend against shutdownattacks. We group these defenses into three classes based onthe layer in the CAN communication stack they operate on.Defenses at application layer: Many IDSes are softwareapplications, limited to reading messages passed up the com-munication stack by CAN hardware. These run on any ECUand do not require special hardware, making them an attractivesolution. For instance, they can use statistical techniques basedon message timings and content [9], [16], [17], [46]. A recentU.S. agency report [12] discusses how companies workingclosely with automakers have access to proprietary informationon the expected content of CAN messages, enhancing theirability to create application-layer defenses. Another class ofIDS that makes use of this proprietary information are machinelearning [43] and traffic anomaly IDSes [44], which analyzemessage timing and payload to detect an attack.

Application-layer IDSes can detect both the diagnostic mes-sage and message overwrite attacks in Table I as they requiretransmitting additional CAN frames on the bus. As such, anyapplication-layer defenses that measure message timing orcontent cannot detect our attack since we do not transmit entireCAN frames or significantly disrupt valid transmitted frames.CANnon operates quickly and can shutdown ECUs in just acouple milliseconds (well under the minimum period observedby prior work [21]) as demonstrated in Sec. VI.Defenses at data link layer: Recent industry solutions pro-pose secure CAN transceivers [13] that operate at the datalink layer. These transceivers can prevent a compromisedECU from attacking a CAN bus by either: (1) invalidatingframes with spoofed CAN IDs, (2) invalidating frames thatare overwritten by a compromised ECU, and (3) preventingattacks that flood the bus with frame transmissions. Attacksthat require physical access are outside their scope.

These transceivers are a promising approach to defendingagainst the diagnostic message and message overwrite attacksin Table I as the transceivers would destroy any illegitimateframes based on their IDs. As the loading phase in ourloading/firing attack transmits a specific arbitration ID (0x0),these transceivers would also detect an illegitimate ID fromthe compromised ECU and raise an alarm. However, the twoattack alternatives (SOF and ACK attacks) do not produce anarbitration ID and could not be detected by pure ID-basedfiltering concepts as demonstrated in Sec. VI.

206

Defenses at physical layer: Another approach for IDSes is todirectly access the physical layer, e.g. measuring bus voltages.These defenses detect sudden changes over a series of CANframes (or even a single frame) by creating a profile of theexpected voltages [10], [11], [45]. These works find that eachECU applies a unique voltage that is measurable across anentire CAN frame. If an illegitimate transmitter attempts tospoof a victim’s message, the voltage measured across theframe could identify a potential attack.

This approach can detect the message overwrite attackbecause a single frame will start with two simultaneous trans-mitters followed by only the overwriting compromised ECU; adistinctive change in voltage for the rest of the frame indicatesan attack. However, in regard to physical-layer defenses thatmeasure voltage, CANnon does not require overwriting a framefrom the SOF onwards and, thus, prior work [45] would notdetect a sudden change in the voltage from the start of a singledata frame as demonstrated in Sec. VI.

B. Deceiving CANnon-aware defenses

We now discuss how CANnon could remain stealthy againsteven future CANnon-aware defenses. We discuss defenses thatmight seem appealing at a glance, but we will show thatthis attack will likely require architectural countermeasuresdiscussed in Sec. VIII.Tracking error interrupts at application layer: Up to now,we have discussed how application-layer defenses that onlymonitor messages do not detect CANnon. However, there isanother source of signals from the lower CAN stack layers:error interrupts. We envision a CANnon-aware defense thatuses these interrupts to identify potentially malicious sourcesof error. This defense tracks errors based on their frequencyand for which messages they occur during in an attempt tofind a pattern representative of a shutdown attack. Existingwork [32] can detect when a shutdown occurs by trackingerror flags, but it cannot determine if the errors were causedmaliciously or by legitimate bus faults. We now discuss acouple modifications that similar work could implement todetect a malicious attack. We also discuss how our adversarycan thwart those efforts by making it challenging for defensesto detect CANnon while maintaining a low false positive rate:

1) Tracking number of errors per ID: One potential defenseis to track the number of errors that occur when a partic-ular message ID is transmitted. However, our adversarycould use prior work [21] to identify all source IDsfrom an ECU by simply monitoring the bus and trackingmessage timestamps. Our adversary could then target allIDs from a victim ECU, making an error seem consistentacross all transmissions and difficult to differentiate froma legitimate fault.

2) Checking for multiple errors in short time: Anotherdefense is to check for multiple errors in a short amountof time, which is an invariant of prior work [15]. Whilethe loading/firing attack causes multiple errors in amatter of milliseconds, an adversary can extend thisattack over a longer period of time. An active error

flag will increment the victim error counter by eight;to recover from an error, a successful transmission froma victim will decrement the error counter by one. Ouradversary could launch an error flag for one of everyseven successful transmissions from a victim, giving usan effective increase of one for the transmit error count.By repeating this attack 256 times, the adversary couldallow up to 1792 successful transmissions by a victimand still succeed in a shutdown.

VIII. COUNTERMEASURES

As illustrated, CANnon-based attacks are stealthy againstexisting security methods. Here, we describe some directionsfor potential countermeasures. Since the attack relies on twobroad ideas, namely clock control and error exploitation, thecountermeasures described can be seen to prevent one of theseproblems, i.e. prevent clock control or detect specific errorpatterns or error transmitter patterns.Detecting bit-wise voltage spikes: Overwriting a messagecauses a sudden voltage change in the dominant bit. Thus,one approach to detect such an attack is tracking per-bitvoltages at the physical layer. Changes in the middle of mes-sage transmissions could indicate potential adversary activity.However, since random faults or genuine errors flags can causesimilar behaviour, such a method would require additionalidentification of patterns in the voltage changes, e.g. behaviourperiodicity. Some recent work that uses transition characteris-tics for network fingerprinting [33] could be modified in thisdirection.Forced clear of transmit buffers: As observed in Sec. III,the ability to resume a message transmission is a key factorfor successfully exploiting the controller. Thus, the attackcan simply be prevented by disabling such behavior, i.e.resetting/clearing all buffers upon clock gating. Such a coun-termeasure allows the flexibility of being deployed at either thehardware or software level. If hardware changes are permitted,this approach can be achieved by designing reset logic basedon the clock signal. In software, this approach can be achievedby flushing the peripheral transmit buffers upon clock stop.A modification of this idea for safety is present in SPC58,whereby a clock stop request is completed based on thefeedback from the CAN peripheral.On-chip power analysis: The automotive industry takesanother approach to protecting their ECUs from remote ad-versaries: host-based IDSes [12]. One host-based detectionmethod for CANnon could be a separate secure chip thatmonitors the power usage of the MCU. Since disablingthe peripheral clock induces a drop in power, a host-basedIDS could detect potentially malicious actions. This approachshould operate outside of the MCU and could include logicto identify when power drops are not expected, e.g. while inmotion, while vehicle not asleep, etc.Removal of CAN peripheral clock gating: The main featurethat enables CANnon in modern MCUs is peripheral clock gat-ing. Rather than offering a peripheral for CAN, modern MCUscould simply utilize a separate always-on clock domain for the

207

CAN peripheral or require standalone CAN controllers, whichreceive a clock signal from a separate oscillator. Assuming theother peripherals do not share this vulnerability, they couldremain unchanged by removing clock gating for just CAN.

IX. OTHER RELATED WORK

Side-channel attacks and fault attacks: CANnon has somesimilarity to fault attacks on cryptographic algorithm imple-mentations available in secure processors, which can com-pletely break the security of secure systems [47]–[49]. Faultattacks [47], [48] are a subset of side-channel attacks, whichdisrupt normal execution of a (software or hardware) processto compromise a system. Fault attacks typically require phys-ical access to the device under attack to successfully induce afault. To our knowledge, the RowHammer attack [50] is theonly other attack that is able to successfully produce a remotefault. In contrast, CANnon remotely induces “faults” throughsoftware-only access to the peripheral clock API of unalteredautomotive MCUs.Security API attacks: Attacks on secure embedded pro-cessor APIs were first discovered in prior work [51] (seeother work [52] for an up-to-date survey). The idea behindthese attacks was “to present valid commands to the securityprocessor, but in an unexpected sequence” in such a way that“it is possible to obtain results that break the security policyenvisioned by its designer” [51]. Although similar in aim, ourwork is fundamentally different as CANnon takes advantageof low-level clock-control APIs in current automotive MCUsthat are used to save energy and improve performance (notinput secure key material). CANnon does not target a secureprocessor either, and it focuses in subverting an interface notexternally available to a human subject as in other work [51](i.e. in CANnon, an attacker must first compromise the MCUand gain control of its software).

X. DISCUSSION

In this work, we introduced CANnon, a novel attack methodto exploit the benign clock gating mechanism in automotiveMCUs for exerting arbitrary control over the CAN bus. Weillustrated several methods to achieve precise clock control anduse it to cause remote shutdown attacks. Despite focusing on asingle example class here, we envisage that such a methodol-ogy can be used for other powerful attacks. With the increasingsoftware code base for a modern vehicle, it can be expectedthat there exist exploitable vulnerabilities in connected ECUs.CANnon-based techniques allow the compromise of a singleECU to influence all ECUs on the bus in a stealthy manner.This reason makes the existence of CANnon-relevant interfacesvery dangerous.

In this work, we illustrated the attack capability on two linesof automotive-grade MCUs, and we believe that several otherlines from independent manufacturers can be susceptible tothis attack. We would strongly encourage the research com-munity to identify similar gaps in other processors. Since thisattack exploits a fundamental architectural feature, changes

to mitigate such a class of attacks poses an interesting prob-lem. We illustrated some directions for such changes here.However, designing specific modifications to future securitysystems would require further investigation.

CANnon not only enables new attack methodologies, butit can also be viewed as a capability that can be integratedinto existing software systems for testing. Enabling suchinvestigations is one of our key motivations for making thetool widely available [20]. We illustrate a few future directionsbelow.Expanding existing tools: Recent work [21] demonstratesa network mapper for the CAN bus. This approach requiresthe tool to operate from customized hardware rather than anin-vehicle ECU. By using CANnon to target and shut downECUs for destination mapping, network mapping could runon existing ECUs without modification. Further, the CANnonmethod could be utilized by a genuine node, e.g. an IntrusionPrevention System (IPS), to remove malicious messages fromthe bus. Prior to CANnon, such IPS capabilities typicallyrequire hardware changes.Clock control for other peripherals: Future work couldinvestigate the impact of the CANnon-like vulnerability forother peripherals. It is possible that other bus protocols,including transport layer protocols that use CAN for the datalink layer (e.g. GMLAN, MilCAN, UAVCAN, etc.), are likelyvulnerable to a network participant that maliciously holds thestate of the bus. For example, the Local Interconnect Network(LIN) bus implements the same logical bus states as the CANbus and is likely vulnerable to the basic remote disruptionattack.Non-standard CAN: Automakers are starting to implementextended CAN and CAN-FD protocols. These protocols relyon the same principles as standard CAN and thus are vul-nerable to CANnon. Future work could investigate uniqueimplications related to these other CAN implementations (e.g.perhaps the higher bit rate for the data payload in CAN-FDcould enable unique derivations of the CANnon attack).

ACKNOWLEDGMENTS

This work was funded in part by the PITAXVIII PITAaward and the CNS-1564009 NSF IoT award. We thank theanonymous reviewers for their helpful suggestions.

REFERENCES

[1] S. Checkoway, D. McCoy, B. Kantor, D. Anderson, H. Shacham,S. Savage, K. Koscher, A. Czeskis, F. Roesner, T. Kohno et al., “Com-prehensive experimental analyses of automotive attack surfaces.” inUSENIX Security Symposium, vol. 4. San Francisco, 2011, pp. 447–462,http://static.usenix.org/events/sec11/tech/full papers/Checkoway.pdf.

[2] K. Koscher, A. Czeskis, F. Roesner, S. Patel, T. Kohno, S. Checkoway,D. McCoy, B. Kantor, D. Anderson, H. Shacham et al., “Experimentalsecurity analysis of a modern automobile,” in 2010 IEEE Symposiumon Security and Privacy. IEEE, 2010, pp. 447–462, https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=5504804.

[3] S. Nie, L. Liu, and Y. Du, “Free-fall: hacking tesla fromwireless to can bus,” Briefing, Black Hat USA, pp. 1–16, 2017,https://paper.seebug.org/papers/Security%20Conf/Blackhat/2017 us/us-17-Nie-Free-Fall-Hacking-Tesla-From-Wireless-To-CAN-Bus-wp.pdf.

208

[4] C. Miller and C. Valasek, “Remote exploitation of an unaltered passengervehicle,” Black Hat USA, vol. 2015, p. 91, 2015, http://illmatics.com/Remote%20Car%20Hacking.pdf.

[5] P.-S. Murvay and B. Groza, “Dos attacks on controllerarea networks by fault injections from the software layer,”in Proceedings of the 12th International Conference onAvailability, Reliability and Security. ACM, 2017, p. 71,http://www.aut.upt.ro/∼pal-stefan.murvay/papers/dos-attacks-controller-area-networks-fault-injections-from-software-layer.pdf.

[6] A. Palanca, E. Evenchick, F. Maggi, and S. Zanero, “A stealth, selec-tive, link-layer denial-of-service attack against automotive networks,”in International Conference on Detection of Intrusions and Malware,and Vulnerability Assessment. Springer, 2017, pp. 185–206, https://www.politesi.polimi.it/bitstream/10589/126393/1/tesi palanca.pdf.

[7] A. Van Herrewege, D. Singelee, and I. Verbauwhede, “CANAuth - ASimple, Backward Compatible Broadcast Authentication Protocol forCAN bus,” in ECRYPTWorkshop on Lightweight Cryptography 2011,2011.

[8] B. Groza, P. Murvay, A. V. Herrewege, and I. Verbauwhede, “Libra-can: A lightweight broadcast authentication protocol for controller areanetworks,” in Cryptology and Network Security, 11th InternationalConference, CANS 2012, J. Pieprzyk, A. Sadeghi, and M. Manulis, Eds.,vol. 7712. Springer, December 12-14, 2012, pp. 185–200.

[9] H. M. Song, H. R. Kim, and H. K. Kim, “Intrusion detection systembased on the analysis of time intervals of can messages for in-vehiclenetwork,” in 2016 international conference on information networking(ICOIN). IEEE, 2016, pp. 63–68, https://ieeexplore.ieee.org/iel7/7422341/7427058/07427089.pdf.

[10] K.-T. Cho and K. G. Shin, “Viden: Attacker identification on in-vehiclenetworks,” in Proceedings of the 2017 ACM SIGSAC Conference onComputer and Communications Security. ACM, 2017, pp. 1109–1123,https://arxiv.org/pdf/1708.08414.

[11] W. Choi, K. Joo, H. J. Jo, M. C. Park, and D. H. Lee, “Voltageids: Low-level communication characteristics for automotive intrusion detectionsystem,” IEEE Transactions on Information Forensics and Security,vol. 13, no. 8, pp. 2114–2129, 2018, https://ieeexplore.ieee.org/iel7/10206/4358835/08306904.pdf.

[12] An assessment method for automotive intrusion detection system per-formance. https://rosap.ntl.bts.gov/view/dot/41006.

[13] B. Elend and T. Adamson, “Cyber security enhancing can transceivers,”in Proceedings of the 16th International CAN Conference, 2017.

[14] J. Wilson and T. Lieu, “Security and privacy in your car study act of2017 — H. R. 701,” 2017, available at https://www.congress.gov/115/bills/hr701/BILLS-115hr701ih.pdf.

[15] K.-T. Cho and K. G. Shin, “Error handling of in-vehicle networksmakes them vulnerable,” in Proceedings of the 2016 ACM SIGSACConference on Computer and Communications Security. ACM,2016, pp. 1044–1055, https://rtcl.eecs.umich.edu/wordpress/wp-content/uploads/ktcho busoff CCS 16.pdf.

[16] ——, “Fingerprinting electronic control units for vehicle intrusiondetection,” in 25th {USENIX} Security Symposium ({USENIX} Security16), 2016, pp. 911–927, https://www.usenix.org/system/files/conference/usenixsecurity16/sec16 paper cho.pdf.

[17] S. U. Sagong, X. Ying, A. Clark, L. Bushnell, and R. Poovendran,“Cloaking the clock: emulating clock skew in controller area net-works,” in Proceedings of the 9th ACM/IEEE International Conferenceon Cyber-Physical Systems. IEEE Press, 2018, pp. 32–42, https://ieeexplore.ieee.org/iel7/8429083/8443707/08443719.pdf.

[18] C.-W. Lin and A. Sangiovanni-Vincentelli, “Cyber-security for thecontroller area network (can) communication protocol,” in 2012 Inter-national Conference on Cyber Security. IEEE, 2012, pp. 1–7.

[19] C. Smith, The Car Hacker’s Handbook: A Guide for the PenetrationTester. No Starch Press, 2016, http://opengarages.org/handbook/.

[20] Cannon. https://github.com/sksecurity/cannon.[21] S. Kulandaivel, T. Goyal, A. K. Agrawal, and V. Sekar, “Canvas: Fast and

inexpensive automotive network mapping,” in 28th {USENIX} SecuritySymposium ({USENIX} Security 19), 2019, pp. 389–405, https://www.usenix.org/system/files/sec19-kulandaivel.pdf.

[22] T. Ring, “Connected cars–the next targe tfor hackers,” Network Security,vol. 2015, no. 11, pp. 11–16, 2015.

[23] Gartner says by 2020, a quarter billion connected vehicles willenable new in-vehicle services and automated driving capabilities.https://www.gartner.com/en/newsroom/press-releases/2015-01-26-

gartner-says-by-2020-a-quarter-billion-connected-vehicles-will-enable-new-in-vehicle-services-and-automated-driving-capabilities.

[24] The car in the age of connectivity: Enabling car to cloud con-nectivity. https://spectrum.ieee.org/telecom/wireless/the-car-in-the-age-of-connectivity-enabling-car-to-cloud-connectivity.

[25] C. Miller and C. Valasek, “A survey of remote automotive attacksurfaces,” black hat USA, vol. 2014, p. 94, 2014, http://illmatics.com/remote%20attack%20surfaces.pdf.

[26] Experimental security research of tesla autopilot. https://keenlab.tencent.com/en/whitepapers/Experimental SecurityResearch of Tesla Autopilot.pdf.

[27] Car hacking research: Remote attack tesla motors. https://keenlab.tencent.com/en/2016/09/19/Keen-Security-Lab-of-Tencent-Car-Hacking-Research-Remote-Attack-to-Tesla-Cars/.

[28] New car hacking research: 2017, remote attack tesla motors again.https://keenlab.tencent.com/en/2017/07/27/New-Car-Hacking-Research-2017-Remote-Attack-Tesla-Motors-Again/.

[29] D. Wise, “Vehicle cybersecurity dot and industry have efforts under way,but dot needs to define its role in responding to a real-world attack,”Gao Reports. US Government Accountability Office, 2016.

[30] Microchip sam 3x family of mcus. http://ww1.microchip.com/downloads/en/devicedoc/atmel-11057-32-bit-cortex-m3-microcontroller-sam3x-sam3a datasheet.pdf.

[31] Microchip sam v family of automotive mcus. http://ww1.microchip.com/downloads/en/DeviceDoc/SAM-E70-S70-V70-V71-Family-Data-Sheet-DS60001527D.pdf.

[32] S. Longari, M. Penco, M. Carminati, and S. Zanero, “Copycan: Anerror-handling protocol based intrusion detection system for controllerarea network,” in ACM Workshop on Cyber-Physical Systems Security& Privacy (CPS-SPC’19), 2019, pp. 1–12, https://re.public.polimi.it/retrieve/handle/11311/1104918/427927/CopyCAN.pdf.

[33] M. Kneib, O. Schell, and C. Huth, “Easi: Edge-based sender identi-fication on resource-constrained platforms for automotive networks,”https://dl.acm.org/doi/pdf/10.1145/3338499.3357362.

[34] Automotive semiconductor market - growth, trends, and forecast(2020 - 2025). https://www.mordorintelligence.com/industry-reports/automotive-semiconductor-market.

[35] Nxp mcus. https://www.nxp.com/docs/en/application-note/AN4240.pdf.[36] Renesas mcus. https://www.renesas.com/us/en/products/synergy/

hardware/microcontrollers/glossary.html.[37] Fujitsu mcus. https://www.fujitsu.com/downloads/EDG/binary/pdf/find/

25-5e/5.pdf.[38] Cypress mcus. https://www.cypress.com/products/fm4-32-bit-arm-

cortex-m4-microcontroller-mcu-families.[39] Infineon mcus. https://www.infineon.com/dgdl/Infineon-TC1767-DS-

v01 04-en.pdf?fileId=db3a30431be39b97011bff8570697bdb.[40] Sam v71 xplained ultra evaluation kit. https://www.microchip.com/

DevelopmentTools/ProductDetails/PartNO/ATSAMV71-XULT.[41] Spc58ec-disp discovery board. https://www.st.com/en/evaluation-tools/

spc58ec-disp.html?ecmp=tt12221 gl social jul2019.[42] St spc5 family of automotive mcus. https://www.st.com/en/automotive-

microcontrollers/spc5-32-bit-automotive-mcus.html.[43] K. Zhu, Z. Chen, Y. Peng, and L. Zhang, “Mobile edge assisted literal

multi-dimensional anomaly detection of in-vehicle network using lstm,”IEEE Transactions on Vehicular Technology, vol. 68, no. 5, pp. 4275–4284, 2019.

[44] M. Russo, M. Labonne, A. Olivereau, and M. Rmayti, “Anomalydetection in vehicle-to-infrastructure communications,” in 2018 IEEE87th Vehicular Technology Conference (VTC Spring). IEEE, 2018, pp.1–6.

[45] M. Foruhandeh, Y. Man, R. Gerdes, M. Li, and T. Chantem, “Simple:Single-frame based physical layer identification for intrusion detec-tion and prevention on in-vehicle networks,” 2019, http://u.arizona.edu/∼yman/papers/simple acsac19.pdf.

[46] C. Young, H. Olufowobi, G. Bloom, and J. Zambreno, “Automotiveintrusion detection based on constant can message frequencies acrossvehicle driving modes,” in Proceedings of the ACM Workshop onAutomotive Cybersecurity. ACM, 2019, pp. 9–14, https://lib.dr.iastate.edu/cgi/viewcontent.cgi?article=1066&context=ece conf.

[47] D. Boneh, R. A. DeMillo, and R. J. Lipton, “On the importanceof checking cryptographic protocols for faults (extended abstract),” inAdvances in Cryptology - EUROCRYPT ’97, ser. LNCS, W. Fumy, Ed.,vol. 1233. Springer, May 11-15, 1997, pp. 37–51.

209

[48] E. Biham and A. Shamir, “Differential fault analysis of secret keycryptosystems,” in Advances in Cryptology - CRYPTO ’97, ser. LNCS,B. S. K. Jr., Ed., vol. 1294. Springer, August 17-21, 1997, pp. 513–525.

[49] S. P. Skorobogatov and R. J. Anderson, “Optical fault induction attacks,”in Cryptographic Hardware and Embedded Systems - CHES 2002, ser.LNCS, B. S. K. Jr., C. K. Koc, and C. Paar, Eds., vol. 2523. Springer,August 13-15, 2002, pp. 2–12.

[50] Y. Kim, R. Daly, J. Kim, C. Fallin, J. Lee, D. Lee, C. Wilkerson, K. Lai,and O. Mutlu, “Flipping bits in memory without accessing them: Anexperimental study of DRAM disturbance errors,” in ACM/IEEE 41stInternational Symposium on Computer Architecture, ISCA 2014. IEEEComputer Society, June 14-18, 2014, pp. 361–372.

[51] M. Bond and R. J. Anderson, “Api-level attacks on embedded systems,”IEEE Computer, vol. 34, no. 10, pp. 67–75, 2001.

[52] R. J. Anderson, Security engineering - a guide to building dependabledistributed systems (2. ed.). Wiley, 2008.

210