TTIDS: Transmission-resuming Time-based Intrusion Detection System for Controller Area Network (CAN)

Modern vehicles are becoming complex cyber-physical systems equipped with numerous electronic control units (ECUs). Over the controller area network (CAN), these ECUs communicate with each other to share information related to vehicle status as well as commands to efficiently control the vehicle. However, the increasing complexity of modern vehicles has inadvertently expanded potential attack surfaces, making them vulnerable to cyber attacks. In light of this, researchers are currently working to demonstrate remote vehicle maneuvering by compromising ECUs, and as a countermeasure to such malicious manipulation, to study automotive intrusion detection systems (IDSs) as potential remedies. In general, CAN messages are transmitted periodically, and as such, many researchers have relied on frequency-based IDSs in their solutions proposals. However, an attacker can bypass this defense by suspending the communication of the target ECU from the network and injecting malicious messages with the same frequency as the suspended messages. As a result, an attacker is able to masquerade as the original transmission frequency. In this paper, we propose a Transmission-resuming Time-based IDS (TTIDS), which is designed to detect such attacks. TTIDS detects when an ECU periodically transmitting messages is suspended, and then it estimates when the suspended ECU resumes periodic transmission. With this projection, TTIDS detects malicious messages transmitted while the ECU is suspended. We conduct the evaluation of TTIDS on two real vehicles and present the results, which show the TTIDS is able to effectively detect an enhanced attack that bypasses existing frequency-based IDSs with a false positive rate of 0.213% and a false negative rate of 0.027%.

the CAN protocol is that it cannot verify if incoming CAN messages originated from valid ECUs or other sources. Ever since the car hacking demonstration by Koscher et al. in 2010, there has been increasing research regarding cyber attacks on a vehicle [3]. Car hacking is no longer science fiction, and myriad information about vehicle hacking is readily available on open Internet platforms like YouTube [4]. Because the CAN was designed solely for communication efficiency and stability-and not for security features-it is difficult to introduce cryptographic protocols into ECUs while maintaining standard CAN specifications [5].
The automotive intrusion detection systems (IDSs) analyze in-vehicle network traffic, and security researchers identify these systems as promising attack detection tools as they do not require any modification of existing hardware or CAN protocol. Indeed, research and development of automotive IDS products now extend beyond the academic domain. According to the University of Michigan Transportation Research Institute (UMTRI), several companies worldwide are developing automotive IDS products [6]. In response to this finding, UMTRI helmed a project on methods for evaluating the performance of these emerging products, implying that vehicle OEMs are planning to install automotive IDSs into vehicles in the very near future. In addition, United Nations Economic Commission for Europe (UNECE) regulations for the Cybersecurity Management System and Software Update Management System have been adopted by UNECE's World Forum for the Harmonization of Vehicle Regulations [7], [8].
In one variety of typical attacks on a vehicle, an attacker continuously injects a large volume of maliciously crafted messages into the CAN bus to force the receiving ECU to process the malicious messages. To detect these attacks, automotive IDSs mainly zero in on two characteristics. Since most CAN messages are periodically transmitted on the CAN bus, the periodicity of message transmissions is commonly used as a pattern for analysis purposes to detect an automotive intrusion [9][10][11][12][13][14][15]. As this periodic pattern can be measured simply and analyzed without special equipment, most commercialized versions even leverage these patterns to detect vehicular intrusions. The frequency-based IDS uses this periodicity pattern. Another commonly utilized pattern is the content of data payload (i.e., data field). Since part of the contents implies a vehicle status, there is no rapid change in normal conditions. Accordingly, machine learningbased (ML-based) IDSs learn these patterns and detect intrusions by verifying the consistency or plausibility of the data payload [16][17][18][19]. The consensus is that the most difficult attack to detect is a masquerade attack that injects malicious messages by mimicking the original transmission periodicity and data payload [20][21][22]. In a masquerade attack, an attacker first suspends message transmission from a target ECU and then uses a compromised ECU to inject the malicious messages with the same frequency and consistent data payload as the suspended messages. There is no difference between normal and malicious messages when it comes to transmission periodicity or content of their data payload. As a result, no frequency-based or ML-based IDSs are able to properly detect the masquerade attack. Indeed, most works for frequency-based or ML-based IDSs have not yet been able to provide evaluation results proving detection of a masquerade attack. Unfortunately, these IDSs are not designed to detect this advanced attack because it is assumed that these attacks perfectly masquerade periodicity and slowly change the content of a data payload. Even though the clock-based IDS [20] was subsequently designed to detect a masquerade attack, one recent study proves that clocks can be emulated, meaning that the clock-based IDS can be also bypassed [23], [24].
In contrast to the existing models, we present a novel method to detect a masquerade attack based on the fact that an ECU is supposed to be suspended before message injection starts in a masquerade attack. We focus on how an attacker stops message transmission from a particular ECU and when the suspended ECU will resume working. To date, two types of methods have been introduced for ECU suspension: one type is to employ diagnostic services, and the other one is to employ a bus-off attack. We designed an automotive IDS based on the Transmission-resuming Time (dubbed TTIDS) to detect a masquerade attack, which is an advanced attack. Our novel proposal is designed to simply recognize when an ECU is suspended by diagnostic services or a bus-off attack. Then, TTIDS estimates when a suspended ECU will resume its function. If CAN messages suspected to be from a suspended ECU are observed, our method considers these messages as intrusive.
The key contributions of our paper are as follows: 1) We propose a novel method that is able to detect a masquerade attack without any additional hardware. 2) According to the ways to suspend an ECU, we conduct two types of masquerade attacks on real vehicles. Through this evaluation, we show that our TTIDS method can be applied to current systems in real vehicles without any hardware modification. 3) We systematically classify ECU behaviors when ECUs are suspended and resume functioning. Based on our analysis, TTIDS is able to reliably estimate when transmission from a suspended ECU will resume.

II. RELATED WORKS
This section introduces various existing methods on how to suspend message transmission of an ECU as the suspension of ECU is the initial step in a masquerade attack. In addition, we summarize related works on automotive IDSs.

A. ECU SUSPENSION
There are two ways to suspend message transmission of a particular ECU. The first method is to use diagnostic services, which Koscher et al. [3] described to illustrate how ECU communication can be deactivated this way. Miller and Valasek [25] and Nie [26] both proposed a method to suspend an ECU transmitting CAN messages when the ECU is held in a special diagnostic mode. These works put the Electronic Parking Brake Module (EPB/EPBM) ECU into a special diagnostic session mode and make it stop transmitting messages. The open-software tool for diagnostic service scanning, such as the Caring Caribou tool [27], enables diagnostic services to be scanned and its parameter applied to the vehicles on the application layer.
The second method is to leverage a bus-off attack, in which an attacker takes advantage of the confinement mechanism rules defined by the CAN specification [28][29][30][31]. In busoff mode, an ECU can neither transmit nor receive CAN messages on the CAN bus. Two ways to put an ECU into bus-off mode have been introduced. The first way requires a non-standard CAN controller [28], [29]. The attacker identifies the CAN ID of the target data frame and intentionally transmits a dominant bit at a recessive bit position to generate a bit error. Due to this error, the target ECU transmits an error flag and retransmits the failed data frame again. With each error, the target's transmission error counter (TEC) increases by 8, and the attacker can eventually force the target ECU into bus-off mode. However, as described by Longari et al. [32], this attack is hardly feasible without previous physical access to the in-vehicle network since physical modification of the CAN controller of the attack device is necessary to successfully implement this strategy. Also, the second way does not require the CAN controller to be modified [30], [31]. The attacker intentionally can increase the TEC of the target ECU by transmitting a message with the same CAN ID as the target message but with different data and at the exact same time, thus generating a bit error. By repeating this process, the target's TEC quickly exceeds the threshold of 255, and it enters bus-off mode. However, the preceded CAN messages are required to match transmission timing. Iehira et al. [33] proposed a spoofing attack method that uses a bus-off attack. The attacker transitions the target ECU into bus-off mode by using a bus-off attack and transmits malicious messages at the same frequency as the regular messages.

B. AUTOMOTIVE INTRUSION DETECTION SYSTEMS
To prevent cyber attacks on vehicles, researchers sought to improve the security of CAN communication by applying cryptographic protocols [34][35][36][37]. However, cryptographic methods required modification of current ECU software and negatively impacted CAN communication by causing heavy busload or low response times. Following this, automotive intrusion detection systems (IDSs) entered as a promising method to handle cyber attacks on the CAN protocol as these new frameworks did not require vehicle component modification.
The self-adapting nature of automotive IDSs allows for easy application in the CAN of actual vehicles, and hence, researchers have extensively studied methods to incorporate automotive IDS frameworks [9][10][11][12][13][14][15][16][17][18][19], [38], [39]. To date, the simplest approach is to make an automotive IDS check legitimate CAN identifiers (IDs) [38], [39]. Because the number of legitimate CAN IDs is relatively small (usually less than 100), malicious CAN messages with invalid CAN IDs are easily detected. However, this simple approach can be easily evaded by injecting messages with valid CAN IDs and forged data payloads.
Since most CAN messages are periodically transmitted on the CAN bus, the periodicity of CAN messages is also one of the characteristics used in automotive IDS technologies [9][10][11][12][13][14][15]. The injection of malicious CAN messages clearly increases transmission frequency or changes the statistical characteristics related to periodicity. The frequency-based IDS is the type that uses this periodicity pattern. Another commonly utilized pattern is the content of data payload (i.e., data field). Since a part of the contents implies a vehicle status, there would be no rapid change in normal condition. Accordingly, ML-based IDSs learn these patterns and detect intrusion by verifying the consistency or plausibility of data payload [16][17][18][19]. Still, any frequency-based or ML-based IDSs are unable to properly detect a masquerade attack by an advanced adversary who may be able to successfully mimic the original transmission periodicity and a data payload. In the masquerade attack, there is no difference between normal and malicious messages when it comes to their transmission periodicity and content of their data payload.
In contrast to the existing works, our approach focuses on the fact that an ECU is supposed to be suspended before message injection starts in a masquerade attack. Our method is designed to recognize a suspended ECU. If CAN messages that are supposed to be from the suspended ECU are observed, our method considers these messages as an intrusion regardless of the transmission periodicity or a data payload.

III. BACKGROUND ON CAN PROTOCOL
Next, we present background on the CAN protocol to facilitate a closer understanding of how our method operates.

A. CAN FRAME PRIORITIZATION
According to the CAN standard, four different frame types are defined: data, remote, error, and overload. In an in-vehicle network, ECUs normally communicate with each other with the data frame. As shown in FIGURE 1, a CAN data frame contains fields for the identifier (ID), the data length code (DLC), the data, and the cyclic redundancy check (CRC). The identifier field (11 bits in the standard frame format or 29 bits in the extended frame format) refers to the CAN message identifier that determines the frame's priority and is related to a particular function (i.e., engine temperature or throttle valve angle). Note that since IDs are uniquely assigned to CAN messages, we use the terms "CAN message" and "CAN ID"  (0) and (1), respectively. If one ECU transmits a dominant bit (0) and another ECU transmits a recessive bit (1), the dominant bit will dominate the bus. Therefore, during the arbitration decision process, the lowest ID indicates the highest priority and wins the arbitration. The ECU that loses arbitration stops transmitting its messages and re-transmits when the CAN bus is idle once more.

B. ERROR HANDLING
For fault-tolerant communication in the CAN protocol, the error-handling mechanism is implemented so that ECUs can automatically detect and resolve transmission errors and take appropriate action, such as discarding a frame, retransmitting a frame, or broadcasting an error flag. There are five types of errors in CAN: bit, stuff, form, ACK, and CRC. Each node maintains both the transmit error counter (TEC) and the receive error counter (REC). Depending on the role of the ECU, these counters will increase when an error is detected, or alternatively, they decrease after a successful transmission or reception. When a transmitter encounters an error, it transmits an error frame and increases TEC by 8. Similarly, when a receiver encounters an error, it should transmit an error frame and increase REC by 1. When there is error-free transmission and reception, an ECU decreases both TEC and REC by 1.
To provide fault confinement, the CAN specification defines three error states as illustrated in FIGURE 2. All ECUs start in error-active mode and determine their error state  according to the value of both counters. An error-active ECU can normally take part in bus communication and send an active error flag when an error is detected. When TEC or REC exceeds 127 as a result of consecutive errors, the ECU changes to error-passive mode, which prohibits the transmission of active error flags. Instead, a passive error flag is sent upon detection of an error. Finally, when TEC exceeds 255, the ECU enters bus-off mode, which wholly limits its influence on the bus. In this state, the ECU stops transmitting or receiving messages on the CAN bus. The ECU is permitted to automatically revert back to the error-active mode after 128 occurrences of 11 consecutive recessive bits (1) on the bus are monitored [2]. In addition to the CAN controller, the microcontroller also stops requesting transmissions for a period of time when it recognizes bus-off mode. Normally, the microcontroller is interrupted by its CAN controller when it enters busoff mode, but the implementation of the microcontroller for bus-off recovery is not standardized [30]. Unlike the CAN controller, when bus-off mode is detected by the microcontroller, how long it is suspended for is determined by manufacturers. It is also possible for the microcontroller to remain suspended until it is manually re-initialized. However, microcontrollers for the ECUs that we checked for this paper initialize automatically from bus-off mode. Note that other studies have also stated that the vehicles they analyzed had ECUs with an automatic initialization mechanism from busoff mode [40][41][42].

C. UNIFIED DIAGNOSTIC SERVICES (UDS)
The Unified Diagnostic Services (UDS), codified in ISO-14229, is a diagnostic communication protocol used over the CAN protocol for vehicle diagnostics [43]. UDS has become an essential tool for manufacturers and technicians   TABLE 1 shows typical examples of the services provided by UDS along with descriptions. A message for UDS services is constructed in the data field of the CAN data frame as shown in FIGURE 3. In the data field, the Service ID (SID), sub-function, and parameters associated with diagnostic services are contained. UDS messages are transmitted via a CAN bus with a specific request CAN ID, and ECUs choose whether or not to filter these message based on their request CAN IDs. It is known that the common range of diagnostic IDs is from 0x700 to 0x7FF [44]. Since a UDS message is always directed at a particular ECU, the ECU should respond to the request with a diagnostic response ID. If the requested SID, sub-function, and parameters are correct on the ECU, a positive response should be sent; otherwise, a negative response should be sent. A positive response is characterized by the addition of value 0x40 to the SID. A negative response is characterized by an error ID of 0x7F and negative response code (NRC) [45]. Therefore, the request and response messages can be identified by the diagnostic request ID and the diagnostic response ID, respectively. An attacker widely exploits to launch various attacks on vehicles via UDS services [46]. According to experiments by Miller and Valasek [47], an attacker would be able to transmit some diagnostic messages to kill engine or control fuel gauge of the Ford and Toyota in their models.

A. ATTACKER CAPABILITIES
According to car hacking demonstrations [25], [48], an attacker may access the in-vehicle network either physically or remotely. The on-board diagnostics (OBD) port is a typical interface that enables physical access, and a telematics device can be also used as an interface to enable remote access to the in-vehicle network. In our attack model, we simply assume that the attacker is able to access the in-vehicle network regardless of physical or remote access. Moreover, we presume that the attacker may have knowledge about which CAN messages are assigned to critical functions of a vehicle, which he could glean from CAN reversing [49][50][51][52] or a publicly available database (e.g., OpenDBC) [53]. Once an attacker accesses the in-vehicle network, he is able to intentionally control the vehicle by injecting malicious CAN messages. As a result, an attacker is then able to conduct a masquerade attack so that the frequency-based automotive IDS is easily bypassed.

B. ATTACK TYPES
As mentioned earlier, our method is designed to detect a masquerade attack, which is the most advanced attack that can bypass existing automotive IDSs. We divide masquerade attacks by ECU suspension methods because ECU suspension attack is the initial step of any masquerade attack. A masquerade attack normally bypasses frequency-based IDSs since it does not necessarily alter the original transmission frequency of a CAN ID [20][21][22]. The attacker only needs to suspend one target ECU so that it cannot transmit CAN messages, and he then transmits the malicious messages with the same CAN ID of the suspended ECU at the original frequency. Next, we describe two ways the attacker suspends message transmission: i) suspension using the UDS services and ii) suspension using bus-off attack.

1) Suspension using UDS services
In this attack strategy, the attacker uses diagnostic services to suspend transmission of normal messages from the target ECU. After the target ECU is suspended, the compromised ECU transmits malicious messages at the same frequency as the original messages normally transmitted by the target ECU. FIGURE 4 (a) illustrates how a masquerade attack using UDS is performed on the CAN bus. An attacker can use three diagnostic services (SIDs)-DiagnosticSessionControl (0x10), CommunicationControl (0x28), and TesterPresent (0x3E)-to suspend ECU message transmission [25], [26]. When the vehicle is powered on, the ECU enters the default session where it transmits messages and listens for UDS requests. At this point, the DiagnosticSessionControl (0x10) service is used to switch to an extended diagnostic session in the ECUs that start in the default session. Note that ECUs with a non-default session return to the default session after a time-out. If an additional diagnostic request message is received before the time-out, the duration of a non-default session is extended. Accordingly, an attacker is able to disable message transmission of an ECU by periodi- VOLUME 4, 2022 This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/ This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication.

2) Suspension using Bus-off Attack
In a bus-off attack, an attacker takes advantage of the errorhandling mechanism rules in the CAN specification [28][29][30][31].
Each time an error is detected while an ECU transmits a CAN message, the TEC increases by 8 until it exceeds 255 and forces the ECU to enter bus-off mode. As mentioned in Section II-A, there are two ways to intentionally generate an error on the CAN bus so that a target ECU is forced to enter bus-off mode. An attacker uses a non-standard CAN controller [28], [29] or a standardized CAN controller [30], [31] to generate errors when a target ECU transmits a normal message. Due to an intentional error, the target ECU transmits an error flag and then attempts to retransmit the failed transmission. As a result, the attacker can force the target ECU to increase its TEC by generating an error every time it transmits a normal message. FIGURE 4 (b) illustrates how the masquerade attack using bus-off attack is performed.

C. ASSUMPTIONS
We assume that all ECUs installed in a vehicle either revert back to an error-active state or resume transmission after the ECU enters bus-off mode or the diagnostic communication session terminates, respectively. Even though ECUs can be manually initialized from bus-off mode, all ECUs we checked performed automatic initialization processes. Moreover, we found that the ECUs investigated by research presented in [40][41][42] also contained automatically initializing ECUs from bus-off mode. In addition to this fact, AUTOSAR specification [54] states that ECUs performing a non-default diagnostic session revert to the default session if they have not received diagnostic request messages for 5 seconds (i.e., a time-out).

V. TTIDS
In this section, we present TTIDS that detects a masquerade attack. TTIDS is built on the fact that an ECU must be suspended for a masquerade attack to proceed. We first offer an overview of TTIDS and then divide important details into three steps.

A. OVERVIEW
In an in-vehicle network, TTIDS can be implemented in an existing ECU, such as a gateway ECU, so that it monitors CAN traffic generated from other ECUs. Regardless of physical or remote access, we assume that an attacker intends to compromise an ECU. For a masquerade attack, the attacker must first suspend a target ECU before malicious CAN message injection. As mentioned in Section IV-B, the attacker is able achieve this suspension via UDS service or bus-off attack. FIGURE 5 shows a system overview of TTIDS, where it can be seen that a target ECU is suspended and TTIDS analyzes CAN traffic to detect an abnormal pattern due to the suspension. TTIDS is divided into three steps: i) suspension detection, ii) transmission-resuming time estimation, and iii) malicious message classification. In the first step, suspension detection, TTIDS monitors the in-vehicle network to detect when an ECU is suspended. In the transmission-resuming time estimation step, TTIDS estimates when transmission from the suspended ECU is to resume. According to the CAN standard, suspended ECUs are designed to automatically recover from bus-off mode. Finally, in the malicious message classification step, TTIDS distinguishes between normal and malicious CAN messages.

B. SUSPENSION DETECTION
In this step, TTIDS monitors and analyzes CAN traffic in the in-vehicle network to identify any suspended ECUs. For the suspension attack using the UDS service, diagnostic request/response messages can be simply observed on the CAN bus. Accordingly, TTIDS also easily recognizes suspended ECUs even if an attacker employs the UDS service. Normally, an attacker may use a combination of the three UDS services-DiagnosticSessionControl (0x10), CommunicationControl (0x28), and TesterPresent (0x3E)to suspend an ECU. When an attacker suspends a target ECU

C. TRANSMISSION-RESUMING TIME ESTIMATION
Transmission from the suspended ECU should automatically resume if the attacker does not keep transmitting malicious messages and prolong the suspension. TTIDS is able to estimate when an ECU resumes transmission by pinpointing when the suspension attack ends. Depending on the suspension ways, TTIDS estimates the transmission-resuming time as follows.

1) Transmission Resumption from UDS Services
An ECU can be suspended by a combination of the UDS services-DiagnosticSessionControl (0x10), Commu-nicationControl (0x28), and TesterPresent (0x3E). In particular, for DiagnosticSessionContol, a sub-function of 0x03 should be coupled, implying that the "Extended Diagnostic Session" is a sub-function. After the diagnostic session is enabled, an ECU is suspended for a certain time-out d if it receives the diagnostic message for CommunicationControl (0x28) with sub-function "Disable Tx and Rx for ECU." To maintain the suspension, a diagnostic message for Com-municationControl (0x28) or TesterPresent (0x3E) should be transmitted before time-out. If transmissions for Com-municationControl (0x28) or TesterPresent (0x3E) repeat, suspension is also extended. Accordingly, an attacker can use these UDS services to suspend the message transmission of the target ECU. Moreover, TTIDS can estimate when a suspended ECU will revert to the default session mode and message transmission will resume by checking if it takes timeout d after transmission of CommunicationControl (0x28) or TesterPresent (0x3E).

2) Transmission Resumption from Bus-off Attack
When a CAN controller recognizes that its TEC exceeds 255, it normally reports this to its microcontroller via an interruption. Even though the response operation to this interruption is not standardized, we discovered that ECUs in real vehicles share commonalities in terms of how they recover from bus-off mode. Thanks to this commonality, TTIDS is able to estimate when bus-off recovery is complete and when transmission will resume. According to the CAN standard, a CAN controller in bus-off mode should wait until there are 128 occurrences of 11 consecutive recessive bits to resume transmission. However, we found that all ECUs (i.e., microcontrollers) are programmed to conduct additional operations during bus-off recovery. Namely, the ECUs we analyzed additionally wait for a particular time duration, which is elsewhere recommended for safe CAN communication [55]. The three parameters-wait time, controller recovery type, and timer behavior-are used so that TTIDS can estimate most reliably. We elaborate on these three parameters next. FIGURE 7 shows a timeline for message transmission affected by bus-off mode, by which it can be seen that how an ECU is suspended by bus-off mode and how it recovers.

a) Waiting Time
The first concern is how long a microcontroller will wait after bus-off mode is detected. According to Copperhill Technologies Corporation [55], recovery should not be immediate as to give other ECUs the chance to catch up or recover. In this context, immediate recovery means that a microcontroller would not conduct any operation for bus-off recovery, and the CAN controller would simply reset. Accordingly, the wait time would be minimal before bus-off mode is complete, typically taking only hundreds of milliseconds. We define this wait time as denoted by d. All ECUs we analyzed have a static duration for wait time d. In particular, some ECUs wait for the static number of timer interruptions rather than VOLUME 4, 2022  b) Controller Recovery Type According to the CAN specification, CAN controllers should be initialized from bus-off mode after there are 128 occurrences of 11 consecutive recessive bits. We found there are two instances of recovery when CAN controllers start initialization from bus-off mode. One instance immediately starts initialization by counting the 128 occurrences of 11 consecutive recessive bits when the TEC exceeds 255. Regardless of the microcontroller waiting out wait time d, the CAN controller can recover. Accordingly, CAN controllers in bus-off mode may already recover before the microcontroller completes the wait time. The other instance of recovery starts initialization after the microcontroller completes the wait time. We refer to these two processes as immediate recovery and wait-then-recovery, respectively. Even though both types of CAN controllers may seem identical, there is a difference in terms of when the microcontroller and its CAN controller recover from bus-off mode and are ready to resume transmission. In addition, some CAN controllers flush out messages backed up in buffers during bus-off mode. If a buffer is flushed out after a CAN controller recovers, these messages are thought of as first transmissions. In other words, the suspended transmission by bus-off mode immediately resumes when bus-off recovery is complete. This type of transmission can be estimated only with the two parameters wait time and CAN controller recovery.

c) Timer Behavior
The final concern is timer behavior during bus-off recovery. For periodic transmissions on the CAN bus, microcontrollers are periodically interrupted by timers, such that message transmissions are requested. All the timers we analyzed do not operate identically during bus-off mode. Since there is no standard for timer implementation, it seems that this depends largely on developers. However, we typically categorize timer behavior into three types: initialized, suspended and alive. Before we describe the behaviors of each type, we present the following equation for estimating when the first message will be newly transmitted after a successful bus-off recovery.
where m new is the first transmitted message after bus-off recovery. t[m new ] is the time when m new is transmitted on the CAN bus. t[BO] is the time when a CAN controller enters bus-off mode. Normally, 32 error frames are needed for an ECU's TEC to exceed 255. r is the amount of time needed for 128 occurrences of 11 recessive bits for the wait-thenrecovery type. A is the amount of time determined by timer behavior.
Initialized Timer. This timer initializes as soon as busoff recovery is complete. Upon initialization, the timer interrupts its microcontroller so that message transmission can be newly requested. As a result, A = 0 becomes the initialized timer, and the first message after the bus-off recovery m new is seen the time as follows.
r is the amount of time determined by 128 occurrences of 11 consecutive recessive bits. (If immediate recovery controller is given, r = 0) n is a positive integer.
Suspended Timer. Unlike the initialized timer, the suspended timer does not interrupt after bus-off recovery. This timer is merely suspended and does not count down during bus-off mode. Accordingly, it waits until the remaining clocks run out before it enters bus-off mode. For example, if a timer that periodically interrupts every 100ms counts 15ms before bus-off mode, it would additionally count 85ms (100ms -15ms) after bus-off recovery. The first message after bus-off recovery m new is seen the time as follows.
where T is a time period for timer interruption. Alive Timer. The alive timer continuously counts clocks even during bus-off recovery, and the microcontroller is still interrupted by this type even during bus-off mode. In other words, message transmission interruptions occur just the same as when bus-off mode does not occur. Of course, transmission requests during bus-off mode are ignored, and transmission requests after bus-off recovery are processed normally. Accordingly, we obtained the following equation to estimate transmission of the first message after bus-off recovery, in which m new indicates the alive timer.
, where T is the periodicity of the transmission suspended during bus-off mode, and n is the first positive integer that satisfies the condition t[m i ] + n × T > t[R]. The t[R] is determined by d and r. If the microcontroller enters bus-off mode and completes bus-off recovery within a single period , denoted as T , there would be no difference with when the first message m new is seen outside of bus-off mode (n = 1). Figure 8 shows an example of message transmissions according to the behavior of the three timers. Timer behavior can be determined by analyzing the time intervals of two consecutive messages. As a result, TABLE 2 outlines the criteria determining behavior.

D. CLASSIFICATION BETWEEN NORMAL AND MALICIOUS MESSAGES
In the above steps, we described how TTIDS detects a suspended ECU and estimates when message transmission will resume. With the correct interval of suspension, TTIDS is able to classify between normal and malicious messages during a masquerade attack. CAN messages that are observed before an ECU is suspended and after it is resumes should be classified as normal; on the other hand, CAN messages that are observed in the time interval during ECU suspension should be classified as malicious.

VI. EVALUATION
In this section, we perform a series of experiments to evaluate TTIDS and report our observations.

A. EXPERIMENTAL SETUP
TTIDS was evaluated on the CAN bus of two real vehicles (named Vehicle A and Vehicle B). In order to perform the a bus-off attack, we employed the hardware and software used in [40] conducted by Sekar et al. By attaching the hardware to the OBD-II port of the vehicle, we were able to generate errors on the CAN bus to force a particular ECU to enter busoff mode. FIGURE 9 shows our experimental setup along with the real vehicles used in our experiments.
For performance metrics, we utilized a typical metric for error rates in a binary test. The false positive rate (FPR) and the false negative rate (FNR) are additionally defined to measure the performance of our method. In this evaluation, a "false positive" refers to the case in which a malicious CAN message is incorrectly identified as normal (i.e., missed detection) and a "false negative" refers to the case in which a normal CAN message is incorrectly identified as malicious (i.e., false alarm).

B. DISCOVERY OF DIAGNOSTIC PARAMETERS
Since no DBC format file was provided for Vehicle A and Vehicle B, we searched for diagnostic ID pairs implemented   Response  CAN ID  SID  Subfunction ID  Time-out  Waiting  time   Controller  recovery type  Timer behavior   Vehicle   A   A  0x018, 0x034, 0x050, 0x110,  0x120, 0x510, 0x517   0x7A0  0x7A8  0x10  0x03  5 s  70 ms  Immediate recovery  Suspended  0x771  0x779  0x28  0x03  0x3E  0x00   B  0x042, 0x043, 0x044, 0x350  0x7B3  0x7BB   0x10  0x90  5 s  70 ms  Wait-then-recovery  Initialized  0x28  0x01  0x3E   on ECUs via a query for diagnostic request messages with request IDs ranging from 0x700 to 0x7FF. In doing so, we also discovered valid SIDs, sub-functions, and parameters for the diagnostic services. When an ECU receives a CAN message with a diagnostic request CAN ID, the ECU transmits a positive or negative response with a corresponding diagnostic response CAN ID. Depending on the responses, we can identify the valid diagnostic ID pairs and SIDs. After that, we are able to identify the valid sub-function and its parameters. For example, we discovered that an ECU has a SID of 0x28 for CommunicationControl and a sub-function of 0x03 for "Disable TX and RX". If the ECU finds some invalid sub-function or parameters, then it transmits a negative response message with a negative response code (NRC).
Since we are able to observe via the NRC which parameters are invalid, such as service IDs (SID) or sub-functions, we rather understand which parameters are correct by repeating the transmission of the diagnostic request messages. As a result, we found 6 and 8 diagnostic request/response CAN ID pairs from Vehicle A and Vehicle B, respectively.  and a bus-off attack. Moreover, both techniques produced identical results, and we use these results to verify that the network mapping is correct.

D. DETECTION OF SUSPENDED ECUS
TTIDS is designed to detect when an ECU is suspended. In this subsection, we demonstrate how correctly TTIDS is at detecting a suspended ECU.

E. TRANSMISSION RESUMPTION FROM UDS SERVICES
When an ECU is suspended by UDS services, we can estimate when it will resume by counting how much time elapses after the last diagnostic messages is observed. As mentioned before, the diagnostic messages Communication-Control (0x28) or TesterPresent (0x3E) are transmitted to extend ECU suspension time. If an ECU does not receive any additional diagnostic messages, it automatically returns to the default session. TTIDS measures how much time an ECU takes to return to the default session from when we FIGURE 13: Distribution of time intervals to classify controller recovery types transmit the last diagnostic messages. FIGURE 11 shows the distribution of suspended time duration for one diagnostic message. All suspended ECUs we analyzed start working again approximately 5 seconds after the last diagnostic message is transmitted. From this observation, we conclude that TTIDS is able to estimate when an ECU suspended via UDS services will resume transmission.

F. TRANSMISSION RESUMPTION FROM BUS-OFF ATTACK
With the three parameters-wait time, controller recovery type, and timer behavior-TTIDS estimates when message transmission suspended by bus-off mode will resume. To demonstrate the feasibility of TTIDS, we first checked whether or not the actual ECUs are assigned to parameters VOLUME 4, 2022 FIGURE 14: Time intervals during masquerade attacks using UDS services and bus-off attacks classified. Even though the parameters for each ECU can be provided by automotive manufacturers, we were unfortunately unable to obtain this information. To overcome this limitation, we manually analyzed patterns in transmissions directly affected by bus-off mode. We presented the criteria for determining timer behavior in TABLE 2, and we note that timer behavior can be determined by analyzing the transmission intervals of two consecutive messages during bus-off mode. FIGURE 12 shows the distribution of time intervals for classification of timer behavior, where the parameters of timer behavior can be simply determined. Subsequently, we also checked two distribution types to classify variations in controller recovery. One distribution type applies to time intervals between when bus-off mode starts and recovery completes, making it possible to count clocks in reverse by timer behavior to check where bus-off recovery completes. The other distribution type relates to time intervals between when bus-off mode starts and when waitthen-recovery CAN controller begins recovery. This timing can also be checked by counting in reverse the 128 occurrences of 11 consecutive recessive bits, which is required for automatic recovery. Given these two different distributions, we were able to determine parameters for controller recovery types. Since the wait time is a static number, the controller recovery type is also determined by checking for a static distribution. If the distribution of time intervals between when bus-off mode starts and when recovery completes are relatively normal distribution, the controller recovery type can be classified as the parameter of immediate recovery. FIGURE 13 shows two different distribution models, from which we obtained parameters per ECU by manually analyzing CAN traffic. TABLE 3 shows the parameters we found for each actual ECU.

G. MASQUERADE ATTACK DETECTION
We conducted masquerade attacks on the CAN bus of real vehicles by performing a suspension attack. As mentioned earlier, the suspension attack is performed via either UDS services or a bus-off attack. For UDS services, we transmit a diagnostic request message so that the target ECU is FIGURE 15: Performance of TTIDS under masquerade attacks suspended; at the same time, we inject CAN messages that are originally designed to be transmitted from the suspended ECU. We also inject them at the same frequency as the original frequency of one the suspended ECU transmits. Moreover, we are able to suspend a particular ECU by the bus-off attack. When the target ECU is suspended, we similarly conduct the injection of CAN messages that are designed to be transmitted from the suspended ECU. Our dataset for the masquerade attack and detection code are publicly available to foster further research. 1 FIGURE 14 shows time intervals between two consecutive CAN messages, where blue indicates time intervals of normal CAN messages and red indicates time intervals of malicious CAN messages. As can be seen from the figure, there is no significant difference between normal and malicious CAN messages during a masquerade attack. Accordingly, it is expected that any frequency-based methods for automotive IDSs would be not able to detect a masquerade attack. On the other hand, TTIDS is able to detect such an attack by identifying ECU suspension statuses. FIGURE 15 illustrates the confusion matrices showing the accuracy of TTIDS in detecting masquerade attacks. We obtained an FPR of 0.213% and an FNR of 0.027%. As a result, we conclude that TTIDS reliably detects masquerade attacks that, up to this point, have gone undetected by existing methods.

H. COMPARISON WITH OTHER AUTOMOTIVE IDSS
In this subsection, we compare our method with four existing methods [19], [20], [24], [56] in terms of the four different matters shown in TABLE 4. Ansari et al. proposed a filteringbased automotive IDS that detects a self-identifier violation [56]. Even though this method can be easily applied, SW modification is necessary for filter configuration. This implies that every ECU should conduct additional computation to detect any self-identifier violations. Because they have constrained resources, though, the necessary functions would not be properly provided. Clock-based IDSs detect a masquerade attack by analyzing clock offsets that are inherent characteristics of ECUs [20], [24]. However, these clock offsets are evaluated using a dataset for a simple injection attack because it is difficult to create a dataset for a masquerade attack. In short, existing research has not suspended a real ECU. The injected messages were only assumed to be derived from a masquerade attack. Alternatively, Nowdehi et al. proposed an automotive IDS that analyzes a series of data payloads [19]. Their method detects a masquerade attack when the data payloads demonstrate a high deviation compared with normal ones. Even though these models indeed suspend a real ECU for a masquerade attack, the suspension is only done using the UDS service and there is no bus-off attack conducted to suspend a real ECU-a key improvement in our method. We thus conclude that our method is able to properly detect a masquerade attack more successfully than existing methods.

VII. DISCUSSION
Extended Intrusion Prevention Systems (IPS). TTIDS can detect exactly when an ECU is suspended. If suspended messages are transmitted from the time when the EUC is suspended until the time when the suspended ECU resumes message transmission, the messages are deemed malicious. Therefore, since TTIDS can distinguish between normal and malicious messages in message units, it is possible to expand this framework to an extended intrusion prevention system (IPS) that blocks detected attack messages before transmission is complete. We hope to expand TTIDS into an IPS in future work.

VIII. CONCLUSION
In this paper, we proposed a Transmission-resuming Timebased IDS (TTIDS) to detect masquerade attacks on vehicles. It is widely known that masquerade attacks are the most ad-vanced of attack techniques, and following this, it is difficult for existing automotive IDSs to detect them. The most effective automotive IDSs in existence that use the periodicity of CAN messages are unable to detect injections by advanced adversaries who can suspend the target ECU and mimic the original message frequency. To detect a masquerade attack in these circumstances, we focus on the fact that an attacker must first and foremost suspend transmission in a target ECU. Moreover, according to the CAN standard, the suspended ECU automatically reverts back to the default state. We also systemically analyzed when the suspended ECU will resume its periodic transmission. With this projection, TTIDS can detect malicious messages transmitted while the ECU is suspended. We performed masquerade attacks on two real vehicles to evaluate the performance of TTIDS. Overall experimental results demonstrate a low error rate, a false positive rate of 0.213%, and a false negative rate of 0.027%. In conclusion, TTIDS is able to effectively detect masquerade attacks.