1 Introduction
The automotive industry has undergone a tremendous evolution since the first car was made more than a century ago. While the efficiency and versatility have been continuously evolving, since the early 1980s, manufacturers have constantly been squeezing more and more embedded computers, known as Electronic Control Units (ECUs), into our cars to enhance safety [
33], stability [
4], diagnostics [
6], and comfort [
22,
45], to name a few [
9]. On the one hand, this paradigm shift from the traditional mechanical mechanisms to an all-digital control has been clearly proven beneficial. On the other hand, computerized vehicles open up a broad set of new attack surfaces [
7,
14,
17,
19,
27,
30,
43,
44].
One of the earliest comfort-enhancing inventions is the
Remote Keyless Entry (RKE) system, which eliminates the need for physical keys and allows one to remotely lock and unlock the vehicle
1 merely by using a key fob. Because RKE has already been present in commercial vehicles since the early 1980s [
22], it has been (and still is) one of the main targets of the attackers [
7,
12,
18,
19,
30]. RKE systems use wireless radio signals; due to the limited number of required commands (e.g., lock, unlock) and, most importantly, the power and resource constraints of the small battery-operated key fobs, the communication between the key fob and the vehicle is designed to be simple. Some deployments may use encryption to avoid eavesdropping (i.e., capture and decoding of signals) or tampering attacks (i.e., “flipping” lock signals to unlocks). However, replaying signals, even if they are encrypted, is straightforward. Today, many RKE systems still implement static codes to control the vehicle from the key fob. Therefore, capturing an encrypted “unlock” signal allows an attacker to replay it and access the vehicle anytime afterward.
To cope with these simple replay attacks,
rolling codes, i.e., code hopping [
24], have been introduced wherein a particular code
2 (e.g., an “unlock” code) is considered disposable, i.e., it is only used once. In a nutshell, every button click on the key fob triggers a counter in the key fob and in the vehicle upon reception to roll, making it valid for subsequent use in the future. Put differently, sent codes that are
used once are invalidated by the next code, effectively preventing replay attacks (see Figure
1(a)).
Note that a sent code can also be considered
unused if the key fob has emitted the signal but the vehicle did not receive it. An example of this is when the unlock button is accidentally pressed (i.e., in our pocket, or when our toddler plays with the key fob) outside of the vehicle’s vicinity (depicted by “unlock code n+2” and “n+3” in Figure
1(a)). To avoid getting out-of-sync and hence locking ourselves out of our vehicle in such cases, rolling code–based systems provide a safety feature that allows the key fob’s counter to be steps ahead compared with the vehicle’s counter. This is achieved by having
not one but a set of valid “future codes” maintained at the vehicle. If the received code from the key fob matches any of these future codes, the vehicle resynchronizes to the code in the last key fob signal and invalidates all previous (but unused) ones from this set (refer to “Unlock code n+4” in Figure
1(a)). Clearly, if an attacker could obtain one of these unused future codes (i.e., capture the signals of the accidental button presses outside of the vicinity of the car), and she can replay it before the owner uses the key fob again, the attacker can get access to the vehicle (see Figure
1(b)). However, obtaining these future codes are extremely difficult in practice, especially if an attacker wants to target a random victim. That is the reason why this safety provisioning is considered a handy feature that makes the key fob use seamless and less troublesome.
In 2015, a somewhat sophisticated attack technique called RollJam [
18] proved the rolling code–based key fob systems to be breakable. In a nutshell, by using a careful sequence of signal jamming, capturing, and replaying, RollJam can effectively convert this safety provisioning feature into an exploit.
RollJam is based on four main “principles”:
(i) capturing unlock signals,
(ii) jamming the frequency band towards the vehicle at the same time to hinder correct signal reception,
(iii) the owner’s second trial as a fail-over mechanism, and, most importantly,
(iv) timely replay of previously captured signals. To this end, a special-purpose device (hereafter,
rolljam device) is used as a man-in-the-middle proxy and a signal jammer between the key fob and the vehicle (see Figure
2(a)). Briefly, the victim is lured to
(iii) press the unlock button in a key fob twice by
(ii) jamming the first unlock signal. At the same time, both first and second unlock signals are
(i) captured; however, when the second signal is jammed, the rolljam device quickly
(iv) replays the one captured the first time. As a result, the vehicle acts as intended, i.e., unlocks, and the victim assumes that the signal reception was poor on the first try. On the other hand, the attacker (i.e., by the rolljam device) becomes aware of the following valid unlock signal (see more details in Section
2.3). Therefore, once the owner stops using the vehicle and leaves it unattended, the attacker can replay this signal to access the vehicle.
RollJam, however, has two main drawbacks. First, suppose that the owner unlocks the vehicle again without the rolljam device in action. In this case, the rolling code in the RKE system advances, invalidating all previous codes, including the one possessed by the attacker. Consequently, properly suffixing the rolljam device at a hidden spot of the vehicle and replaying the valid unlock signal in a timely manner, i.e., step (iv), are the keys to the success of RollJam. Second, similar to the above, if the attacker succeeds in using the captured valid yet unused signal, she cannot use it again; to repeat unlocking the same vehicle in the future, the whole attack must be redone from scratch.
In this article, we present
RollBack, a new time-agnostic replay-and-resynchronize attack. Even though a one-time code becomes invalid in rolling code–based systems, replaying a few previously captured (consecutive) signals can trigger a rollback-like mechanism in certain RKE systems, making all former captured (unlock) signals valid again, hence, the name
RollBack.
3 At the same time, the rollback-like mechanism involves the execution of the instruction encoded in the signals, e.g., unlocking the vehicle.
Consequently, unlike RollJam,
RollBack does not have to keep track of the latest valid yet unused code continuously. In other words, we do not need the long step-sequence
\((i)\rightarrow (ii)\rightarrow (iii)\rightarrow (i)\rightarrow (ii)\rightarrow (iv)\) to be repeated, and
\((iv)\) , every time to eventually access the vehicle (see Figure
2). In general,
RollBack does not need step
(iv) at all, and only requires steps
\((i)\rightarrow (ii)\rightarrow (iii)\rightarrow (i)\) once. Then, replaying the captured signals can unlock the victim’s vehicle
any time in the future and
as many times as desired. This makes
RollBack more flexible and time-agnostic, thereby substantially reducing the exertions required by an attacker.
Interestingly,
RollBack only necessitates the jamming of the first signal (
ii) to acquire the subsequent signal within a relatively brief period by making the victim press the button again. In normal circumstances, however, the time-agnostic nature of
RollBack renders it irrelevant whether the captured signals are received by the vehicle; hence, jamming is not required. See further details regarding this characteristic later in Section
3.
During our analysis,
4 we found that not all vulnerable vehicles and RKE systems are equally susceptible to
RollBack. Therefore, we derive
five different variants of
RollBack with regard to a small set of properties (e.g., number of previously captured signals, sequence of the signals, time frame and pace of replay) required for the successful replay attack. We found that vehicles and RKE systems being the most vulnerable to
RollBack can be unlocked with only
two signals captured any time in the past. Moreover, these two signals do not even have to be strictly consecutive (see our definitions later), i.e., the victim can still use the key fob between the times the attacker manages to capture those two signals. This makes
RollBack particularly alarming as, in addition to the aforementioned appealing properties, it further minimizes the required efforts of the attacker.
One notable enhancement in comparison to RollJam is that
RollBack is
instruction-agnostic, rendering it even more perilous. This implies that the nature of the captured signals, whether they correspond to lock or unlock instructions, becomes inconsequential, thereby simplifying the capturing process even further. Only the last captured and replayed signal needs to contain the desired instruction, specifically the unlock command, in order to gain access to the vehicle (see additional details about this property in Section
5.2).
Similar to RollJam and other RKE attacks, permanent mitigation might be cumbersome if RKE ECU firmware cannot be upgraded over-the-air, requiring calling back whole fleets of vehicles to the factory or dealerships. Some precautionary measures can be applied against signal jamming–based attacks, such as RollJam, by assuring proper signal reception by being close to the vehicle and pressing the lock button for the second try if the first unlock signal is not received. In certain scenarios, e.g., car-sharing use cases, risks can be minimized by disabling the RKE system until the vehicle is unlocked through the car-sharing app (see details in Section
9). Nevertheless, since
RollBack, in essence, is a passive listener in the signal capturing phase without the need of signal jamming, besides the car-sharing advice, none of the previously mentioned approaches are applicable to mitigate
RollBack.
Our main contributions are summarized below:
•
After revisiting keyless entry systems and RollJam in more detail (see Section
2), we propose
RollBack (see Section
3). In contrast to RollJam, it can unlock a vehicle
indefinitely at
any time in the future and
as many times as desired by merely replaying previously captured (unlock) signals that are already invalid. Hence,
RollBack is more effective.
•
We delineate a (hidden) property of today’s RKE systems that mimics the
modus operandi of
RollBack, hence making it the most relevant candidate to be the root cause of the vulnerability (see Section
8). However, for the time being, we could not ascertain whether our attack exploits an implementation bug or a limitation inherited from the design of the key fob re-synchronization or learning feature.
•
Through a currently limited yet ongoing real-world experiment, we scrutinize the effectiveness of
RollBack on a variety of popular vehicles
5 from different regions of the world. We show that around 40% of the RKE implementations worldwide are vulnerable to
RollBack (see Section
4) and the Asian regions seem to be more affected.
•
We propose five different variants of RollBack based on the requirements, e.g., number of different signals to capture and replay, the time frame and pace of replay, and the consecutiveness of the signals.
•
We also discuss that, due to the re-synchronization and instruction-agnostic property of
RollBack and the typical human behavior, astute attackers can rely on capturing lock signals to either fasten the signal capturing process (without signal jamming) or to cover the tracks by locking the vehicle again (see Section
5).
•
While the root cause of the attack is unknown mostly due to the lack of documentation, access to resources, and knowledge, we delineate a key fob learning process, as a potential root cause, that mimics the behavior or RollBack.
•
Finally, we discuss possible mitigation strategies; some are precautionary measures the vehicle owner can take when
RollBack requires signal jamming and advice to car-sharing services that are particularly vulnerable to
RollBack (see Section
9). We also discuss possible practical mitigation, e.g., using timestamps.
3 RollBack: A New Time-Agnostic Replay Attack
Next, we propose
RollBack, a new time-agnostic replay attack, which by exploiting a hidden property in the RKE systems overcomes the limitations of RollJam. In particular,
RollBack can unlock a vehicle by simply capturing and replaying a few already invalidated unlock signals at
any time in the future and
as many times as desired without the need of recapturing any further signals later on.
12 In what follows, we describe the threat model of
RollBack by using the same setting as shown for RollJam (i.e., by applying signal jamming) to ease the comparison. However, while jamming can fasten the attack process, unlike RollJam,
RollBack does not necessitate signal jamming at all.
3.1 Threat Model and the Operation of RollBack
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.
3.1.1 Reconnaissance Phase.
The attacker places the
RollBack-device near the car that is locked and left in public (e.g., in a parking lot). When the victim comes back to his/her car and tries to unlock it via the key fob, i.e., when the victim runs
\(Send_{V}(\mathcal {S}^{i}_{unlock})\) , the
RollBack-device
(i) captures the signal (
\(Capture_{A}(\mathcal {S}^{i}_{unlock})\) ), and
(ii) jams the frequency band (
\(Jam_{A}(\mathcal {S}^{i}_{unlock})\) ) to hinder the vehicle from receiving it correctly (recon. phase 1. in Figure
2(b)). As a result, the victim assumes poor reception and
(iii) presses the same unlock button again, i.e., the victim runs
\(Send_{V}(\mathcal {S}^{i+1}_{unlock})\) (recon. phase 2. in Figure
2(b)). This time, the
RollBack-device captures the second consecutive unlock signal (i.e., it runs
\(Capture_{A}(\mathcal {S}^{i+1}_{unlock})\) ).
However, unlike RollJam, it also lets the car receive it, i.e., the attacker
does not run (
\(Jam_{A}(\mathcal {S}^{i+1}_{unlock})\) ). Accordingly, the vehicle unlocks, and the victim drives away, assuming that no harm has been done (idle phase in Figure
2(b)). Note that since
RollBack does not have to keep track of the next valid unlock signal, it is unnecessary to suffix the
RollBack-device to (a hidden spot of) the vehicle. Practically speaking, due to the size of the inexpensive elements needed (see later in Section
3.2), such a special-purpose wallet-size [
13]
RollBack-device can be simply thrown below the vehicle. At the end of the reconnaissance phase (after recon. phase 2. in Figure
2(b)), the attacker becomes aware of two consecutive correct unlock signals. Recall, by the rolling code design, that both captured signals are
no longer valid.
3.1.2 Exploitation Phase.
Unlike RollJam, this phase does not have to follow the first phase directly. In other words, the victim can continue to lock, unlock, and use the car as usual as
many times the victim wants (idle phase in Figure
2(b)). Nevertheless, at any given latter time, once the vehicle is locked, the attacker can unlock the vehicle (without the victim’s authorization) by replaying the previously captured two consecutive unlock signals, i.e., by running
\(Send_{A}(\mathcal {S}^{(i)}_{unlock})\) and
\(Send_{A}(\mathcal {S}^{(i+1)}_{unlock})\) (exploit. phase in Figure
2(b)).
For brevity, our threat model does not cover further intentions of the attacker after unlocking the vehicle. The attacker might steal belongings left inside the car or use other attack methods (if necessary) to steal the vehicle itself.
3.2 Essential Hardware
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]
13), 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.
3.3 Different Variants of RollBack
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.
4 Evaluation
Next, we evaluate RollBack and discuss which vehicles are vulnerable.
Disclaimer.
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.
4.1 Vehicles Evaluated
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.
14 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.
15 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.
18 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.
19 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.
5 Further Appealing Features of RollBack
This section discusses how easily attackers might hide their tracks after accessing a vehicle and shows that RollBack, in certain cases, can be successfully launched with even less effort, i.e., without the need for signal jamming.
5.1 Re-locking the Vehicle After Access
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.
5.2 RollBack is Instruction-agnostic
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.
6 Car-sharing Services: the Most Attractive Targets of RollBack
Car sharing has recently been viral, especially in countries where the cost of ownership for a vehicle is extremely high compared with the average. Car sharing, in essence, makes classic car renting much more accessible, more convenient, and much cheaper. Instead of renting a vehicle for at least a day, doing a lot of paperwork in person, and getting lost among the different insurance policies and waivers, car-sharing costs are significantly lower due to the non-necessity of staff, hour or minute-based conditions, and the convenience of using a mobile application to access and lock the vehicle in the beginning and at the end of the rental, respectively.
The typical steps of car-sharing are as follows. Users (already registered for the service) can use the mobile app to book a car (for a certain period). Once the booking timeslot starts, the user can unlock the vehicle by instructing the mobile application to do so. In the background, the car-sharing company’s service remotely unlocks the vehicle utilizing additional ECUs added to the car for this specific purchase. Once the vehicle unlocks, the user will find the original key fob at a hidden spot in the car (usually in the glove compartment); then,the user can start driving. Note that, typically, there are further steps the car-sharing company might require (e.g., photo-taking, damage checking, and petrol level checking) However, from our attacker’s point of view, they are not relevant. After the user returns the vehicle to a designated parking lot, the individual has to put back the key fob in the hidden spot where it was found in the beginning. To finish the rental, the user has to get out of the vehicle, close all doors, carry out any aforementioned additional steps required by the car-sharing company, and use the application to lock the vehicle.
20An attacker can easily use the key fob to capture the required number of unlocking signals during the rental phase. Since the attacker temporarily owns the vehicle, she might even carry out further tests (e.g., checking which RollBack-variant works and how many signals are required accordingly). Once she returns the vehicle, the rental process officially ends. During that period, the attacker took care of the vehicle well and no harm was done. Later, other users will use the car. An attacker, most of the time, does not even need any effort (e.g., physically following the car, installing a GPS tracker) to keep track of the vehicle. The car-sharing service gives all the necessary information to the attacker. In particular, in point-A-to-A car-sharing, in which each vehicle has a single dedicated lot it has to be returned to in order to finish its rental, the given vehicle’s status and booking schedules are usually available upfront. In the case of point-A-to-B car-sharing, i.e., in which vehicles can be picked up and returned to different places, individual booking schedules might not be available. However, information required for a seamless booking experience (e.g., license plate numbers of nearby vehicles, only showing currently available vehicles) is available through the application. This means that attackers can easily implement crawling scripts to obtain the necessary location information about the target vehicle.
Utilizing such information, the attacker can significantly reduce suspiciousness by waiting for the vehicle to be booked (and used) by several other users. Once there is a time slot when the vehicle is available, the attacker can launch RollBack to access and steal the vehicle (since the key fob is inside the car). Note that since car-sharing companies usually install GPS trackers to keep track of their fleet, stealing the vehicle might be less appealing or requires more effort (e.g., GPS signal jamming). Yet, using the same availability information, the attacker can check when a particular vehicle will be booked in the future. Then, she can approach the vehicle before the scheduled booking starts, wait for the victim to rent the vehicle, and follow the victim until the vehicle is temporarily left, i.e., when it is locked but not returned, for instance, during shopping. The attacker can then use RollBack to unlock the vehicle and steal the belongings left behind.
While one can quickly come up with countless different ways how and when to exploit RollBack and what an attacker might do afterward, due to the simplicity and little effort needed, RollBack is particularly alarming for car-sharing (and classic car-renting) companies, as attackers can do much harm to the rental companies’ user bases, thus, eventually to the companies’ reputations.
7 Responsible Disclosure Process
In this section, we describe our responsible disclosure process, particularly, how we started, what obstacles we bumped into, and eventually, what take-aways we had.
It was not immediately clear to us at the outset whom we should contact with respect to our initial findings. That is, after finding one car make and model vulnerable, should we contact the car manufacturer, e.g., Hyundai, straight away? They would probably ask first: which specific vehicles are vulnerable? Are they the newest models or older ones? Is there any other model from the same make that was found vulnerable? Are all Hyundai vehicles vulnerable? We would have not been able to answer many of these questions due to our limited experiment.
Therefore, we kept experimenting with different vehicles we could have access to until we reached a certain point when 2 to 3 RKE systems using different key fob transponder chips from the same key fob vendor were found vulnerable, irrespective of the vehicle itself.
This led us to two key fob manufacturers: NXP and Omron (see Table
2). While Omron did not have a specific website for reporting vulnerabilities, we have tried to reach out to them through their contact forms found on their international
21 and local
22 (i.e., Singapore) sites. We did not receive any response from Omron. NXP, on the other hand, takes vulnerability disclosure processes very seriously. Vulnerabilities can be reported to their PSIRT (Product Security Incident Response Team), for which all necessary information is provided on their website.
23We had a virtual session with NXP in March 2022. We concluded that the vulnerability that we found is indeed a vulnerability and there is no such feature that exactly works the same way as RollBack. However, the vulnerability is in the receiver side of the RKE system, which manages the rolling codes, and verifies the validity of each code received; the key fob only sends the signals expected by the vehicle.
On the other hand, it is somewhat known that vendors producing key fobs only produce the transponders, and car manufacturers obtain the receiving parts from other OEMs. Accordingly, it is very likely that vehicles using key fobs from other vendors might have the same type of vulnerability due to the supply chain for the receiving units. The key fob manufacturers are (likely) not responsible for the receiving unit, which seems to be the component vulnerable to RollBack.
NXP then kindly assisted us to reach out to the affected car manufacturers via the Automotive Information Sharing and Analysis Center (Auto-ISAC
24). Auto-ISAC is a United States–based industry-driven community that shares and analyzes intelligence about emerging cybersecurity risks to the vehicle and collectively enhances vehicle cybersecurity capabilities across the global automotive industry. The Auto-ISAC members comprise the majority of car and OEM manufacturers worldwide. From our engagement with the relevant car manufacturers, we ended up having two main take-aways from the disclosure process. First, the Auto-ISAC members acknowledged the vulnerability as well as our intention to present our findings (with or without limitations on the context) at Black Hat USA 2022. Second, since our attack targets one specific vehicle (not a fleet of vehicles in general) and has to be redone from scratch for other vehicles (even from the same make/model), it might not be particularly alarming for the car manufacturers.
25 Roughly speaking, there is not much difference between breaking the windows/lock-picking the doors of the target vehicle to steal belongings and doing a more sophisticated and unnoticeable attack such as
RollBack to achieve the same result. Both approaches always need to pick the target, find the right timing, and carry out the attack. Furthermore,
RollBack on its own does not allow an attacker to steal the vehicle itself.
We found that through the recently revealed vulnerability (Rolling-PWN [
21]), the reaction of Honda [
41] has somewhat underpinned our above-mentioned conclusions drawn.
8 Towards Finding the Root Cause
According to the normal operation (discussed in Section
2.2.1 and Section
2.2.2), since the counter value
\(C_{k}\) of the key fob signals replayed by
RollBack is smaller than
\(C_{v}\) , they should be discarded. Thus, when we first discovered this vulnerability, we immediately thought that the phenomenon belongs to some sort of key fob re-synchronization, which is required when a new transmitter (i.e., a key fob) is learned to the receiver (i.e., the vehicle’s RKE system) or when the battery is replaced in the key fob and it might lose its last counter values.
26However, currently, we cannot confirm the root cause of this vulnerability for several reasons. First, datasheets with an explanation on how the system architecture works (including the described learning process) are only available for Microchip offerings [
25,
40]. Therefore, we discuss the key fob learning process in Microchip
KeeLoq systems in detail and point out the critical steps that are not (completely) in line with the operation of
RollBack.
In the
KeeLoq system [
25], the typical learning process is as follows (see Figure
4). After entering into the learning mode, when a button on the new key fob is pressed, the first signal is sent to the vehicle. The signal has an unencrypted part containing the key fob’s serial number and an encrypted part containing the rest of the data, e.g., rolling code counter, discrimination bits, and button pressed.
27 Using the master key added during manufacturing, the receiver in the vehicle generates the correct encryption/decryption key
28 for the key fob using its serial number emitted unencrypted in the first signal. Then, after decrypting the packet using the freshly generated key, the receiver authenticates the signal. Briefly, authentication involves validating the correct key use via the discrimination bits and buffering the counter value
\(C_{k}=n\) . Then, the receiver waits for the second signal, i.e., for the second button press on the key fob. When the second signal is received (and authenticated), the receiver checks whether the transmission is indeed the second one, i.e., whether the second counter
\(C_{k}=n+1\) . The receiver stores the key fob’s serial number, current synchronization counter, and appropriate decryption key upon successful completion of this process. Finally, the system exits from the learning mode. After this point, whenever the freshly added key fob is used in the future, this decryption key is retrieved from the memory along with the stored synchronization counter.
Clearly, the operation of the above-mentioned learning process mimics the operation of RollBack. However, there are five key observations we have to consider, as they are not elaborated sufficiently and they might undermine such a claim accordingly.
8.1 Learn Mode
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].
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.
8.2 Time Frame
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.
8.3 Number of Signals and Their Sequence
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).
8.4 Vehicle’s Reaction
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.
8.5 Relearning the Same Old Key Fob
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.
8.6 Out-of-sync Counters
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).
10 Conclusion
Remote Keyless Entry (RKE) systems have been the target of attackers for a long time. Attacks such as jamming, tampering, and replaying captured key fob signals have been quite common. Thus, since the late 1990s, deployments have implemented rolling code technology that, by invalidating all previous codes every time a button is pressed on the key fob, renders the attackers’ job much more difficult. However, in 2015, RollJam was proven to break, in general, all rolling code–based systems. By carefully jamming, capturing, and replaying key fob signals, RollJam can always be one step ahead of the original key fob, letting an attacker unlock any vehicle. However, if the owner uses the key fob without the RollJam device being in operation (which requires careful placement to hidden spots on the vehicle, continuous control, etc.), the next (unlock) code the attacker possesses becomes invalidated thanks to the rolling codes.
Here, we developed RollBack, a new time-agnostic replay-and-resynchronize attack against most current RKE systems. We showed that even though the one-time code becomes invalid in rolling code systems, replaying a few previously captured signals consecutively can trigger a rollback-like mechanism in the RKE system. RollBack is instruction agnostic, meaning that any captured signals (irrespective of belonging to an unlock or lock instruction) can trigger the same behavior. Therefore, in a typical use case, RollBack does not require signal jamming at all. Furthermore, it is time agnostic; signals have to be captured only once and can be replayed any time in the future as many times as desired.
We derived
five different variants of
RollBack with regard to the required number of signals to be captured, sequence, and time frame of the replay. Our ongoing analysis revealed that
\(\sim 40\%\) of all vehicles tested are vulnerable to a variant of
RollBack, while vehicles manufactured in Asia tend to be more prone to this vulnerability. We also crowd-source a database of the (non-)vulnerable vehicles; anyone can contribute to it by filling out the form available at
https://tinyurl.com/2p99vd7c.
As a countermeasure, we proposed general advice for the vehicle owners on how they could possibly avoid all types of signal jamming-based RKE attacks in different scenarios, including car-sharing use cases that are the most attractive targets for RollBack. However, since RollBack does not necessitate jamming and the root cause of the vulnerability is yet to be identified, adequate countermeasures and patches could not be rolled out easily for the time being.