RollBack: A New Time-Agnostic Replay Attack Against the Automotive Remote Keyless Entry Systems

Next, we briefly discuss the evolution of rolling codes used in RKE systems and define some notations used later in the article. The history of RKE systems reaches back to the 1970s [37], when early motorized garage openers used static codes sent in “plain text” over the air to carry out the intended action (e.g., open, close). However, by merely sniffing and replaying captured signals, attackers were able to easily unlock garage doors. To overcome this issue, rolling codes [24] were introduced, and they have been widely used due to its increased protection (compared with static codes) yet with less computation complexity (compared with the increased protection). The latter property is particularly important as it results in small and simple key fobs with an average battery life of up to four years [46].

There are a few well-known manufacturers providing rolling code–based RKE systems for the automotive industry. For instance, Microchip Technology provides Classic, Advanced, and Ultimate KeeLoq with publicly available documentation and data sheets. On the other hand, semiconductor companies such as NXP [28], Omron, and Texas Instruments also provide proprietary solutions for vehicle manufacturers. For the technical explanations below, we focus on RKE systems using the Classic and AdvancedKeeLoq technology since their documentations are publicly available. Note, however, in essence, all rolling code–based technologies are conceptually similar.

Applying the rolling code technology means that every key fob signal transmission is unique, i.e., it changes with every individual button press. Uniqueness is achieved by incrementing a 16-bit wide counter⁶ in the key fob (and in the vehicle upon reception) with each button press. A button press is valid if the counters at each side are in sync. Then, each of the parties increments its counter⁷ to be in sync for the following button press. Accordingly, if an attacker captures a valid signal sent from the key fob and received by the vehicle with counter \(C_{k} = n\) and replays it, it will be discarded by the receiver in the vehicle as its counter \(C_{v} \gt C_{k}\) , i.e., \(C_{v} = (n+k): k\gt 0\) .

On the other hand, provision is made for cases in which a button is pressed on the key fob while it is out of range of the vehicle, i.e., when using the key fob to lock/unlock the car and \(C_{k} \gt C_{v}\) . These cases are further divided into two different operation windows [25, 40].

In essence, the design of the rolling code scheme should provide a sufficient level of security. However, the earliest deployments have been proven to be breakable. For instance, ClassicKeeLoq technology currently primarily used by garage doors only, was broken by cryptoanalysis [1, 3] and side-channel attacks on the key derivation scheme used by the receiver [8, 20]. Subsequently, enhanced KeeLoq implementations, i.e., AdvancedKeeLoq and UltimateKeeLoq, have addressed these issues by using stronger encryption algorithms and longer keys [40].

Another simple yet efficient method criminals use against rolling code–based key fobs is jamming the signals when victims press the lock button to hinder the vehicle from receiving it correctly. If it happens without the victim noticing it, the car is left unlocked. A more sophisticated variant of this attack is “selective jamming and replaying”: besides the previously mentioned jamming, the attackers also capture the lock signal. Consequently, if this happens again without the victim noticing it, the criminals can lock the vehicle after stealing all belongings to leave a false impression of the car having been left adequately locked. Note that once a signal is captured, without additional knowledge (e.g., encryption keys, command code table), it is impossible to convert it into another signal, i.e., flipping a lock signal to an unlock is infeasible.

Hitag2 from NXP, another widely used RKE scheme using rolling codes, has been used by many car manufacturers worldwide (e.g., Renault, Ford, Chevrolet, Lancia, Opel). Recently, researchers have demonstrated a correlation-based attack allowing the recovery of the cryptographic key and thus cloning the key fob having captured only four to eight rolling codes [12]. Furthermore, the research also revealed that most VW Group vehicles (e.g., VW, Seat, Audi, Porsche) manufactured since 1995 rely on a few master keys. By recovering these keys from the ECUs, an attacker can effortlessly clone the key fob of any such vehicle by only capturing one unlock signal.

In 2015, Samy Kamkar proved all rolling code-based schemes to be breakable with his RollJam [18] attack. RollJam relies neither on any cryptoanalysis nor side-channel attacks; it converts a safety feature into an exploit. In essence, RollJam is an advanced “selective jamming and replaying” method; with a careful sequence of jamming, capturing, and replaying signals, it allows an attacker to capture an unused signal from the key fob that can be replayed later to unlock the target vehicle without the victim noticing it. As briefly discussed in Section 1, RollJam is based on four principles, (i) capturing unlock signals, (ii) jamming the frequency band towards the vehicle at the same time to force the owner (iii) to retry, and (iv) timely replaying of previously captured signals.

The operation of RollJam is summarized in Figure 2(a). When the unlock button is pressed on the key fob, the rolljam device hidden on or near the target vehicle (i) captures the signal and, at the same time, (ii) jams the frequency band towards the vehicle to hinder correct signal reception. Since the vehicle does not respond, (iii) the owner presses the same button again, assuming poor signal reception. This time, however, the rolljam device repeats not only steps (i) and (ii), but also quickly (iv) replays the previously captured signal towards the vehicle (without jamming). As a result, the vehicle acts as intended, i.e., unlocks the doors. In addition, the rolljam device becomes aware of the next valid code for the same action, i.e., it knows what signal to send to unlock the car again in the future. However, if the owner uses the key fob to unlock the car again without the rolljam device in action, the signal the attacker possesses will be invalidated, forcing her to redo the whole process. While RollJam, in general, is effective against all rolling code–based RKE systems, it requires careful and continuous attention due to (iv).

Recently,¹⁰ an attack called Rolling-PWN [21] saw the light of day and hit the headlines of several online news sites, e.g., the New York Post [2], The Drive [38], and Security Affairs [31]. The authors of Rolling-PWN found that Honda vehicles manufactured between 2012 and 2022, implementing rolling code–based RKE systems, are vulnerable to replay attacks. In particular, the authors found a somewhat similar behavior to RollBack;¹¹ sending the unlock commands in a consecutive sequence to the Honda vehicles will resynchronize the counter. However, the required sequence of codes, exactly how many codes need to be captured and replayed, or any other relevant (hardware-specific) details have not yet been disseminated publicly.

The primary goal of the attack is to unlock a vehicle without the victim’s authorization (and, potentially, the victim noticing). Like in all RKE attacks, the vehicle becomes unlocked the same way as using the original key fob, leaving the car intact.

In our threat model, the attacker has a device that can capture, jam, and replay signals in the frequency band used by the target vehicle. For simplicity, let us call this device RollBack-device. In particular, let \(\mathcal {S}^{i}_{I}\) denote a key fob signal sent towards the vehicle with a rolling code counter \(i \in \lbrace 1, 2, ..., 2^{15}\rbrace\) and an instruction \(I:=\lbrace unlock,lock\rbrace\) . For instance, \(\mathcal {S}^{534}_{unlock}\) marks an unlock signal with rolling code counter \(i=534\) . Furthermore, let \(Capture_{A}(\mathcal {S}^{i}_{I})\) and \(Jam_{A}(\mathcal {S}^{i}_{I})\) denote that an attacker A captures the key fob signal \(\mathcal {S}^{i}_{I}\) and jams the frequency band toward the vehicle, respectively, at the same time, i.e., when \(\mathcal {S}^{i}_{I}\) was sent by the victim. Finally, let \(Send_{V}(\mathcal {S}^{i}_{I})\) and \(Send_{A}(\mathcal {S}^{i}_{I})\) mark when the victim (V) and the attacker (A) send \(\mathcal {S}^{i}_{I}\) using the original key fob and using a special-purpose device intended to replay captured signals, respectively.

The functioning of RollBack (see Figure 2(b)) can be categorized into two distinct phases: reconnaissance and exploitation.

For our comprehensive analysis, we use Software Defined Radio (SDR) devices. In essence, these devices have wireless receivers (and transmitters) that can be fine-tuned via software, for instance, in which frequency domain they should listen to signals. One of the most well-known commercial-off-the-shelf (COTS) devices is HackRF One [11], which is capable of both transmitting and receiving signals, and costs \({\sim }{300\!-\!400}\) USD at the time of writing. The COTS software, called gqrx can be used to easily identify the exact frequency used by the key fob to transmit the signals. On the other hand, since all key fobs operate in the licensed spectrum, they all (must) have a unique registered identifier with the U.S. Federal Communications Commission (FCC). Therefore, one can look up the publicly available details of a key fob by keying in its FCC ID at https://fccid.io/. Once the correct frequency is identified, the other COTS software, called Universal Radio Hacker (URH, [34]¹³), can be used to control SDR devices, i.e., to practically capture and replay (the unlock) signals. To jam the frequency using the SDR device, an attacker has a large variety of options. What the attacker chooses depends completely on her appetite and knowledge. For instance, she might use inexpensive programmable development boards and radio transmitters, such as Arduino-based deployments, or even a Raspberry Pi with a full-fledged operating system and RTL-SDR dongles [36] for reception and/or CC1101 transceivers for jamming [39].

Note that, essentially, RollBack relies on the exact hardware requirements as RollJam. Moreover, since jamming is not necessarily needed (see Section 3) for the success of RollBack, a RollBack-device has even less requirements. Therefore, it would cost no more than 20-30 USD [15].

Note, furthermore, that similar to RKE attacks (e.g., RollJam), RollBack does not necessitate execution in an isolated environment. Just as in a regular scenario in which one unlocks a vehicle using RKE in a crowded parking lot, the simultaneous use of other RKE systems has a minimal impact on the success of the attack. The crucial factor lies in the attacker’s ability to capture the signals; replaying them can be done easily and repeatedly, if necessary, at any given time. Moreover, during the signal capture process, the capturing device’s signal reception bandwidth window is intentionally narrowed down compared with the vehicle’s bandwidth windows (see Figure 3). This allows effective jamming of the vehicle’s bandwidth window without hindering the attacker’s signal capture capabilities.

When we first discovered the vulnerability, we had tested a pretty outdated vehicle, a Nissan Latio from 2009 (see details in Section 4.1). In this case, RollBack had the following properties.

Naturally, first, we identified how many signals we needed to replay. In the case of the Nissan Latio, this number turned out to be only two; however, as we will show, other vulnerable systems might require more than that. Accordingly, the first (and most important) property of RollBack is the number of signals (i.e., #SIGNALS) an attacker has to capture (and replay).

The second observation we had is that the attacker strictly has to run \(Capture_{A}(\mathcal {S}^{i}_{unlock})\) and \(Capture_{A}(\mathcal {S}^{i+1}_{unlock})\) and replay them in the same sequence. Put differently, capturing and replaying, for instance, \(\mathcal {S}^{i}_{unlock}\) and \(\mathcal {S}^{i+k}_{unlock} : k\gt 1\) does not trigger the expected rollback-like mechanism. Hence, we call the second property SEQUENCE and it can be Strict (as in the case of the Nissan Latio mentioned before), or Loose if it is not required, i.e., when replaying signals in the capturing (i.e., ascending) order is sufficient but there could be further valid and forfeited signals in between.

Furthermore, in the case of the Nissan Latio, we observed that the two consecutive unlock signals have to be replayed within 5 seconds; otherwise, RollBack is unsuccessful. We termed the third property TIMEFRAME; it indicates the maximum number of seconds that can elapse between two signals when replayed. We indicate TIMEFRAME as \(\bigotimes\) when there is no limit on the maximum number of seconds. When \(\texttt {TIMEFRAME} \ne \bigotimes\) , we confirmed the value of TIMEFRAME, by carefully trimming gaps between the captured signals to exactly \(N=\lbrace 1, 2, 3, 4, 5, 6, 7, 8, 9, 10\rbrace\) seconds. Then, we saved the signals, replayed them, and observed whether RollBack succeeds. Note that once the signals are captured, TIMEFRAME can be easily adjusted via the SDR software by cutting or copy-pasting the breaks or background noises between the signals.

During our analysis (detailed later in Section 4), we derived five different versions of RollBack regarding the properties mentioned above. The different combinations are summarized in Table 1.

For our experiments, we did not carry out any attempts with RollBack in the wild. All tests were executed in an isolated environment, where no other vehicles and/or key fobs were in close proximity. Note, however, as mentioned in Section 3.2, isolated environment is needed to execute RollBack in the wild. All captured signals (for the tests) were stored temporarily only; after capturing the signals and replaying them, the data was removed permanently immediately. We stored two key fob signals for a longer period, i.e., \(\sim 100\) days, to validate RollBack’s time-agnostic feature. Afterward, those stored signals were also removed permanently. Note that replaying key fob signals do not cause any harm to the vehicle, the key fob, and the whole electronic ecosystem irrespective of being vulnerable to RollBack. Thus, the tested vehicles continue to work and behave as usual.

This article is the first publicly disseminated, detailed written information about our findings and about RollBack in general. We used the shorter and more condensed preliminary versions of this document during our attempts t initiate disclosure processes with RKE chip manufacturers and AUTO-ISAC members. See more details about the disclosure processes and findings in Section 7.

In the beginning, our examination was confined to a restricted selection of vehicles, primarily focusing on Asian makes and models prevalent in Singapore. However, following the presentation of our initial discovery [5], numerous automotive cybersecurity experts, passionate enthusiasts, and car owners have endeavored to replicate RollBack against their own vehicles. In fact, RollBack has even been successful in different domains, e.g., smart door locks [23]. Nevertheless, many have shared their findings by contributing to our publicly accessible crowd-sourced database.¹⁴ The vehicles examined and their relevant data are detailed in Table 2 and Table 3. Model date means the time frame the actual model was in production, whereas the Mfg. date denotes the actual manufacturing date of the vehicle we tested. Such information can usually be obtained by using the vehicles’ identifier, i.e., their vehicle identification numbers (VINs), and publicly available services.¹⁵ The region refers to the geographical region where the vehicle is used and registered, which potentially implies the manufacturing location as well.

Different vehicles and their key fobs use different frequencies. However, since the used frequency did not have an impact on whether the vehicle is vulnerable to RollBack (see Section 2.1.3), we omit the exact frequency bands. We could also obtain the exact RKE manufacturer and chip version and serial number most of the time by manually disassembling the key fobs.¹⁸ When disassembling the key fob was either infeasible or the chip(s) on the PCB were obscured (e.g., via black paint), we tried to gather manufacturer information by keying in its FCC ID at https://fccid.io/ or looking for spare key fobs on different retailers’ sites. The found chips are detailed in the penultimate column of Table 2 as well as in Table 3. If we could not obtain the RKE manufacturer by any of the above-mentioned ways, we left the corresponding cells in Table 2 intentionally blank.

Finally, the last column indicates whether the vehicle — or, more precisely, the RKE system — is vulnerable to RollBack (indicated by the actual RollBack variant that works).

From the experiment (cf. Table 2 and Table 3,), which is continuously being updated, we can conclude the following.¹⁹ First, \(\sim 50\%\) of the examined Asian vehicles were found to be vulnerable to a RollBack variant. However, the examined vehicles in other regions show less vulnerability to Rollback (for now). For instance, we found that Mazda vehicles manufactured in Asia tend to be vulnerable, whereas their European counterparts (even the same model) are not vulnerable to RollBack.

On the other hand, we can observe that the vulnerability is not specific to any sole vehicle, car make, or model. While the age (i.e., model and manufacturing date) does not seem to be a deciding factor (e.g., while Mazda 6 with a model date 2002–2005 is resilient to RollBack, a newer model Mazda Cx-5 with a model date 2018 is prone to the attack), the used RKE system’s manufacturers might be a telltale sign. Specifically, all tested Korean vehicles (such as Kia and Hyundai) employing RKE systems from Omron were found vulnerable in every instance. Notably, the exploit only necessitates the use of two unlock signals, which could even be captured independently in the past (i.e., SEQUENCE=Loose). Drawing similar conclusions about NXP, however, is not possible since the assessment of multiple vehicles equipped with NXP transponders in their key fobs revealed that some were found to be secure while others were deemed unsafe. Furthermore, we observe that all three tested Toyota vehicles, for which we identified the key fob manufacturer as Texas Instruments, turn out to be immune to RollBack. According to further analyses on Toyota vehicles, however, our database showed that this, in general, does not mean that all Toyota vehicles are protected. In particular, Toyota Wigo S and Toyota Rush have been found to be vulnerable. Accordingly, we cannot conclude at the moment whether vehicles equipped with RKE systems from Texas Instruments are generally resilient to RollBack.

Last, but not least, Microchip RKE systems were probably more ubiquitous in the past. However, their rolling code–based solution can still be found in today’s vehicles, which means they might all be vulnerable to RollBack.

We summarize the results on the rest of the vehicles (that either use RKE systems from manufacturers other than NXP/Omron or for which we could not identify the RKE manufacturer) as follows. Fiat 500, Hyundai i20, Mazda 2, Mazda 3, Mazda 6, Mitsubishi Montero GLS, Opel Crossland X, Opel Astra, and Renault Clio have been found to be immune to RollBack. Honda Brio, Honda Mobilio RS Navi, Hyundai ix20, Nissan Latio, and Nissan Navara are prone to RollBack.

According to the latest dataset, 40% of the tested vehicles worldwide turned out to be vulnerable to RollBack. Within this set, 20% do not require the signals to be replayed strictly consecutively, which is particularly alarming. Moreover, in all cases, RollBack requires capturing 2 signals only. Nonetheless, among all vulnerable vehicles, less than 20% require 5 signals to be captured; this number is 38% and 43% for 2 and 3 signals, respectively.

Bear in mind that not the key fob (as it only sends the signals) but its counterpart (i.e., the receiving unit in the car per se) seems to be vulnerable. Moreover, the key fob manufacturer usually produces key fobs (i.e., the transponders) only, and different original equipment manufacturers (OEMs) supply the receiving units. Yet, our results indicate a strong relationship between the key fob manufacturer and the receiving unit as, with the exception of NXP F7953, we have not found any two RKE systems that use the same transponder chip in their key fobs but react differently to RollBack.

Bear in mind that, like other key fob–based attacks such as RollJam, RollBack targets a specific vehicle. The signals captured during the reconnaissance phase of RollBack are unique to that particular car and cannot be utilized across different vehicles regardless of their make, model, or other distinguishing features. For instance, the key fob signals obtained for our Mazda 2 HB (facelift) vehicle are exclusively applicable to that specific vehicle and cannot be applied to compromise an entire fleet of the same Mazda models produced in the same year.

Recall that due to the counter re-synchronization, if subsequent signals are captured and replayed, they also work as expected straight away afterward. Using the notations defined in Section 3.1, assume that the attacker not only captures consecutive unlock signals (e.g., \(Capture_{A}(\mathcal {S}^{i}_{unlock})\) , \(Capture_{A}(\mathcal {S}^{i+1}_{unlock})\) in the case of \(\texttt {RollBack} ^{\texttt {Loose}}_{\bigotimes }(2)\) ) but also captures a following lock signal \(\mathcal {S}^{i+2}_{lock}\) (i.e., \(Capture_{A}(\mathcal {S}^{i+2}_{lock})\) ). In this case, irrespective of whether the victim continues to use the key fob as normal (i.e., whether the last signal received by the car is \(\mathcal {S}^{i+2}_{lock}\) or \(\mathcal {S}^{i+j}_{(un)lock}:j \gt 2\) ), after \(Send_{A}(\mathcal {S}^{i}_{unlock})\) and \(Send_{A}(\mathcal {S}^{i+1}_{unlock})\) (in the case of \(\texttt {RollBack} ^{\texttt {Loose}}_{\bigotimes }(2)\) ), the vehicle unlocks and also re-synchronizes to the counter \((i+1)\) . Accordingly, after the attacker has accessed the vehicle, when running \(Send_{A}(\mathcal {S}^{i+2}_{lock})\) , the car will lock, giving a false feeling to the owner of having the vehicle left adequately locked.

To accomplish re-synchronization using RollBack, the specific instructions within the signals are generally insignificant except for the last signal. Particularly, a combination of lock and unlock signals can be replayed to initiate the counter re-synchronization process. However, it is crucial that the last signal in the sequence is an unlock signal in order to ultimately unlock the vehicle, as the vehicle will respond based on the instructions provided in the final signal. For instance, in the case of \(\texttt {RollBack} ^{\texttt {Loose}}_{\bigotimes }(2)\) , capturing and replaying one lock signal and then an unlock signal is sufficient to unlock the target vehicle. Suppose now that the attacker captures the lock signals emitted when the victim left the vehicle in a parking lot (i.e., \(Capture_{A}(\mathcal {S}^{i}_{lock})\) ). Then, the attacker waits for the victim to come back and unlock the vehicle; this time the attacker runs \(Capture_{A}(\mathcal {S}^{i+1}_{unlock})\) . Recall that, in the case of \(\texttt {RollBack} ^{\texttt {Loose}}_{\bigotimes }(2)\) , the second signal does not even have to be strictly consecutive, i.e., the attacker can simply capture any following unlock signal (e.g., \(Capture_{A}(\mathcal {S}^{i+k}_{unlock}:k\gt 1)\) ) to unlock the vehicle. After replaying these two signals in sequence, the vehicle will be locked and re-synchronized to the counter \((i+1)\) , and the vehicle will react according to the instruction in the last signal, i.e., it unlocks.

This makes RollBack particularly alarming as this signal sequence can be easily captured at once without applying any signal jammer. Moreover, even if the vehicle is susceptible to a RollBack-variant that requires more signals, they can also be captured without jamming due to the following typical human behavior and the vehicles’ safety features. For instance, when we leave something worthy unattended (e.g., the vehicle in the parking lot or the main entry door to our home), we usually confirm whether the locking was done adequately. For this reason, most of us still push (down the handle on) the door of our home after locking to double-check whether the lock itself is not malfunctioning. Similarly, it is always worth pressing the lock button on the key fob once more when we leave our vehicle behind since it confirms adequate locking by flashing the emergency signals and/or honking.

Pressing the lock button again (for a third or even more time) afterward, thereby making the vehicle honk, can also become handy afterward. People tend to use this feature in huge parking lots to locate the vehicle per se.

On the other hand, vehicles usually implement a safety feature when unlocking the car via the key fob. This feature allows the owner to only unlock the driver’s door upon pressing the unlock button for the first time. However, if one does not drive alone, giving access to the other co-riders (e.g., family members), we have to press the unlock button twice to unlock all doors.

These features and usual human factors enable all RollBack-variants to be successfully launched without the need for any signal jammer.

Observe that the learning sequence starts with the step Enter Learn Mode. Depending on the make, model, and build-year, different vehicles implement different yet intricate approaches to put the receiver in the car into learn mode. In other words, to avoid accidentally entering into learn mode, the vehicle (i.e., the RKE system) requires a very uncommon sequence of actions that would not be carried out during normal use. For instance, some Toyota vehicles require the key to be turned in the ignition from OFF to ON and repeat within 5 seconds [29].²⁹ However, RollBack does not require entering into this mode explicitly.

On the other hand, upon a successful learning process, the system should exit from this mode by default (see Exit step in Figure 4). This means that the vehicles found vulnerable to RollBack (see details in Section 4) are either always in a learn mode (i.e., do not exit) or do not have this initial step at all, i.e., synchronizing a new key fob to the vehicle is oversimplified.

As discussed in Section 3.3, some RKE implementations require the captured signals to be replayed within a certain time frame (e.g., \(\texttt {RollBack} ^{\texttt {Strict}}_{{N}}(2)\) ), while others have no such requirement. This property is not defined in the available documentation, e.g., in [25, 40]. However, even [25] claims that the method describes a typical implementation; real-world deployments might be altered to fit other needs.

While the learning process requires the key fob to be pressed two times in a sequence, several RollBack variants we derived work differently. For instance, \(\texttt {RollBack} ^{\texttt {Loose}}_{\bigotimes }(2)\) does not require strictly consecutive signals, whereas other variants, e.g., \(\texttt {RollBack} ^{\texttt {Strict}}_{\bigotimes }(5)\) , need more than two signals. Recall that the learning process described in Figure 4 applies to Microchip’s solutions; however, the previously mentioned RollBack variants work against other RKE manufacturers (see details in Section 4).

Another missing piece from the puzzle is to describe which (i) actual button (and its instructed action) should be pressed, and (ii) whether the same button has to be pressed for the second time. However, since only the key fob’s serial number and the discrimination bits matter during the learning process, pressing two different buttons and sending two different signals (i) to (ii) accordingly should have no impact on the learning process. Put differently, sending a lock signal and an unlock signal should be sufficient to learn a new key fob to the vehicle.

Nevertheless, at the end of the learning process (see Learn Successful in Figure 4), there is no indication of whether the vehicle should react to the second button press with the intended action (e.g., lock the doors if lock button was pressed). However, in the case of RollBack, the intended action in the last signal (e.g., unlock) is always materialized.

There is no information available about what happens if an already learned key fob (e.g., the original key fob) is being re-added to the system. One of the vital steps in the learning process is to save the serial number of the key fob and the accompanying crypt key in memory. Thus, the vehicle can have this information straight away from memory in the future, when the new key fob is used. During the learning process, however, there is no step involved in checking whether the serial number of the key fob is already known (before adding it to the memory). Due to this missing check of the key fob’s serial number as well as the lack of indication how the vehicle should react (cf. Section 8.4), it is unclear whether re-adding an already known key fob is silently ignored (i.e., leaving the system still in learning mode waiting for a new key fob to be added) or re-added as new.

Finally, observe that during the learning process, the counters of the key fob are buffered for the first signal and only stored upon success. However, the counter’s value \(C_{k}\) is not checked (against the counter at the vehicle \(C_{v}\) . This, on the other hand, is somewhat expected. Normally, a new key fob cannot be in sync with the vehicle, hence, the learning process. Furthermore, synchronizing the new key fob’s counters to the counters of the actual key fob we use every day would make no sense at all. The different key fobs are always going to be out of sync due to using one of them at a time; hence, the vehicle’s receiver stores a separate synchronization counter for all key fobs learned. This can be the reason why consecutive but out-of-sync old counters are always accepted without further validations.

While the learning process is the only action we identified in the RKE system that somewhat mimics the operation of RollBack, according to our arguments above, we cannot state with confidence whether RollBack indeed exploits this feature. Nevertheless, if the found exploit is in the learning process, then the vulnerable vehicles are probably unintentionally left in a “forever” learn mode (Section 8.1), which allows re-adding an already learned key fob (Section 8.5) by simply replaying old consecutive signals (Section 8.6), and the vehicle will react accordingly (Section 8.4).

Since RollBack, just like other replay-based attack techniques (e.g., RollJam [18]), can utilize jamming to speed up the whole process, a user should be vigilant for the possibility of exposure to signal jamming. The most important thing is always to be close enough to the vehicle to avoid poor signal reception. Thus, if the first button press was not realized by the vehicle (but the second was³⁰), then there is a high chance of the first signal being jammed (and captured). In such circumstances, the owner may press the lock and unlock buttons interchangeably until (i) both of the two last button presses were correctly received, and (ii) the vehicle acts as intended. If only (i) holds, the owner might still be exposed to continuous attacks such as RollJam, which jams the latest signal and replays a previously captured one. However, with (ii), the owner can definitely rule out the possibility of such attacks taking place.

Additionally, advanced rolling code implementations having precise timestamps besides the counters (e.g., in UltimateKeeLoq [40]) avoid any practical replay attacks because of the time difference between the vehicle and the key fob’s signal.

Note that RollBack does not require jamming at all. Accordingly, since in essence it works as a passive listener during the reconnaissance phase (see Section 3.1.1), there is no way to realize whether one is a victim of RollBack.

While having one rolling code per each learned key fob simplifies the design and reduces the resource requirements, implementing different rolling codes for each instruction will easily evade the problem discussed in Section 5. In particular, by replaying lock signals and hence re-synchronizing its counters, only the further yet invalid lock signals would work. On the other hand, the rolling codes of the unlock instructions would remain intact, still preventing the replay of a single unlock signal to open the vehicle (after re-synchronizing the lock instruction’s counter). This would significantly reduce the easiness of RollBack, requiring signal jamming in almost all cases. As mentioned in Section 9.1, once signal jamming is taking place, a vigilant user can identify it.

Car-sharing companies require additional ECUs to enable their users to unlock and lock their vehicles using the mobile application. There are several options to implement such behavior, e.g., using Internet and API calls and mobile SMS. However, most of the time, that function works independently of the other ECUs in the vehicle. This means that even if the vehicle is locked through this ECU (i.e., via the mobile app), the original RKE system can still be used to unlock the vehicle; hence, it is still vulnerable to RollBack. Therefore, for car-sharing companies, it would be worth “connecting” this additional mobile app–related ECU to the rest of the system and enabling the RKE system only if the vehicle is unlocked through the app (and disabling otherwise). However, this only protects the vehicle after it is returned. When someone renting the vehicle temporarily leaves it in a parking lot adequately locked via the key fob but the rental is still ongoing, RollBack can still be launched.

Similar to RollJam, RollBack is a special case of replay attack. One possible solution to prevent such attacks is to make use of the current time, i.e., actual timestamps, in the signal sent from the key fob to the receiver in the car. The authors of [32] proposed an authentication protocol based on the timestamp and asymmetric cryptographic techniques. There are two phases in the proposed protocol: setup and authentication. The setup phase is executed only once, in the beginning before starting to use the key fob. In the setup phase, a private–public key pair and a seed value are generated at the key fob. The public key and the seed are shared with the receiver in the car. Whenever the user presses the key fob button to unlock the car, the authentication phase takes place. In this phase, a random value is generated from the seed and it is appended to the timestamp. Then, the key fob signs the resultant string with its private key. The signature and the instruction (e.g., unlock) are sent to the car. Since the car receiver has the same parameters (i.e., public key and seed), it can verify the received signature. If the signature verification fails, the instruction will not be executed. When an attacker replays the message (in RollJam or RollBack), the timestamp in the replayed message will be different from the actual timestamp in the receiver, making the signature verification fail. Hence, the attacker’s attempt fails. Note that for such a timestamp-based solution to work, the clocks on the key fob and the car receiver must be synchronized. However, time synchronization–related matters (e.g., clock skews) are out of scope of [32].