How to mitigate vulnerabilities in keyless entry systems

Keyless entry and ignition systems began to appear in production in the late 1990s and early 2000s, and were initially available only on luxury models and other high-end vehicles. Since then, remote/passive keyless entry (RKE/PKE) features have become increasingly common across the industry and are currently available as standard equipment on the vast majority of vehicles sold.

The popularity and convenience of keyless entry technology are indisputable. However, like many other technology-driven advancements, RKE/PKE systems are susceptible to attacks from hackers—and in this case—car thieves. In light of this potential cyber-enabled auto theft, vehicle manufacturers (OEMs) and automotive security experts are working to find ways to mitigate this threat.

RKE systems

RKE refers to entering the car without using a physical key (e.g., using a door keypad or fob). The first RKE key fob used a coded pulse signal generator and a battery-powered infra-red radiation emitter. It was configured to transmit a specific signal, and the car was programmed to respond to that signal.

Taking advantage of this unprotected signal, hackers devised the “classic” replay attack, which uses a device to record and transmit at the same IR frequency as the key fob. When the driver presses the unlock button, the attacker records this signal and can then replay it at a later time to unlock the doors. Note that this hack can only work if the key fob uses the same unlock signal each time the unlock button is pressed.

To prevent such an attack, a rolling code field was introduced into the message sent from the fob to the car to make sure the unlock signal does not repeat. The car and the key fob share two code sequences—one for unlock and one for lock. For example, Xn would be the nth rolling code for unlock while Yn would be the nth rolling code for lock. All sequences are defined using a Cryptographically Secure Pseudorandom Number Generator (CSPRNG). When pressing the unlock button for the nth time, the key fob transmits code Xn. The car then compares the received rolling code with the expected rolling code, unlocking or locking the car accordingly.

This security improvement triggered a new wave of “roll jam” attacks, which were designed to bypass these rolling codes. Roll jam attacks record the rolling codes and jam the RF signal from the key fob, preventing it from reaching the car. This attack scenario consists of the following steps:

1. The driver presses the unlock button, transmitting X1 which is the first code to unlock the car. The attacker jams the signal and learns the value of X1. The car doesn’t receive the signal due to the jamming and remains locked.
2. The driver presses the unlock button again, transmitting X2. The attacker jams the signal and learns the value of X2. Like step 1, the car remains locked.
3. The attacker transmits X1 to unlock the car for the driver.
4. After driving, the driver parks and locks the car by transmitting Y1 which is the expected rolling code for lock.
5. Later that night, the attacker can then transmit code X2 which will unlock the car.

From a security standpoint, the main weakness in the implementation above is that the Lock and Unlock rolling codes are independent of each other. However, simply sharing the rolling code opens up new variations of the roll jam attack. The attacker can still jam consecutive messages, take the rolling code of an unlock command, and then construct a valid lock command (or the reverse scenario beginning with a jammed lock command and constructing an unlock command). Therefore, in addition to sharing the rolling code it is important to sign or encrypt the messages to make sure the attacker can’t construct messages based on the jammed rolling code. This can be done using a recognised and cryptographically secure message authentication code (MAC), such as AES-CMAC or HMAC, with a long shared secret key.

PKE systems

PKE took convenience to a higher level by allowing drivers to enter and start the car without having to take the fob out of their pocket. Building on lessons learned from RKE, a basic PKE communication consists of a challenge transmitted by the car to verify the identity of the key fob and a cryptographically calculated response transmitted by the key fob.

In most PKE implementations, the key fob and car share a long random secret key used to generate and verify the response. The key fob executes a cryptographic function on the challenge, generating the response which is subsequently verified by the car.

Since PKE implementations are based on proximity of the fob, they have an inherent constraint related to the distance the transmitter can reach. The infamous “relay attack” was devised to bypass this distance limitation. Consider a pair of attackers working together. One attacker is near the car and the other is in close proximity to the key fob. Each attacker uses a transceiver that operates over long distances (e.g., via 4G or WiFi) to forward the messages transmitted by the car and the fob.

As depicted below, Attacker A triggers the challenge and forwards it to Attacker B, who then transmits it to the key fob. The key fob answers the challenge and Attacker B forwards it to the Attacker A, who then retransmits it to the car.

Best practices for mitigating relay attacks

One method for mitigating relay attacks is to set an upper bound on the response time. Since waves are propagated at the speed of light, it’s possible to estimate an upper bound of the distance by measuring round trip time from the car’s challenge transmission until the response reception. Using UWB technology, a highly accurate measurement can be achieved.

Another mitigation method is to estimate the key fob location using RSSI (received signal strength indicator), which identifies the distance between fob and car by signal strength. The car transmits the challenge from multiple antennas. The key fob then responds with the RSSI values of each of the antennas, and the car will use those values to estimate the location.

However, there are still ways for hackers to “outsmart” the location estimation algorithm. Since RSSI is measured on the key fob side, a pair of attackers may try to transmit an amplified challenge signal near the key fob to enlarge the RSSI values and “trick” the car into believing the key fob is closer than it really is.

Another issue with this mitigation method is that its values are not signed or encrypted. That means a digital attacker could use a demodulator to extract the data transmitted, modify the RSSI values and then modulate the signal again. If using RSSI for localisation, it’s recommended to sign or encrypt these values.

To try to prevent relay attacks, some key fobs integrate motion sensors to detect long idle periods. If after a couple of seconds/minutes no motion has been detected, the key fob stops answering challenges. In other words, if the key fob is on the kitchen table all night, an attacker can’t perform a relay attack on the car.

Known Challenge relay attack

Another theoretical hacking scenario is a Known Challenge relay attack, which exploits implementations where the challenges are predictable. For example, the next challenge is the previous challenge plus 1: 0, 1, 2, …, 0xFFFFFFFF, or challenges are generated using a random number generator function that is not cryptographically secured, such as LCG, LFSR, etc. In such a case, an attacker who knows the PRNG function or guessed it correctly could construct the full challenge sequence.

Like the classic relay attack (described above), in this scenario the key fob and the car are distant from one another, but this time there is only one attacker. He triggers the challenge from the car and then tries to predict the next challenge the car will transmit. The attacker then moves close to the key fob and transmits the predicted challenge. The key fob answers with a response. Then, the attacker goes back to the car and triggers another challenge. If the triggered challenge is what the attacker predicted, the attacker can solve it by transmitting the response recorded from the key fob to unlock and start the car.

One strategy to consider for preventing this scenario is to make sure the challenges are not predictable by using a recognised CSPRNG with high entropy seed. Another suggestion is to have the car sign all challenges. In this way, even if the attacker is able to predict the challenge, he can’t query the key fob for the response.

Secure implementation is the name of the game

Vehicle theft has been a problem ever since cars were invented. Today, the cat-and-mouse game between security professionals and thieves continues, the only difference being the sophistication of the tools being used.

RKE and PKE create numerous security challenges for OEMs. Insecure RKE implementations are exposed to different variations of replay and roll jam attacks, such as the recently discovered Rollback attack. Messages should be signed or encrypted to prevent an attacker from modifying messages recorded from the key fob.

With respect to PKE implementations, it’s important to make sure challenges are not predictable by using a high entropy seed for randomization and applying CSPRNG to generate encrypted challenges. If using RSSI to estimate location, these values should also be signed or encrypted to prevent tampering.

Moreover, some faulty implementations are mitigatable by upgraded security countermeasures. In many cases, a software update for either the BCM and/or key fob may be enough to fix known vulnerabilities. For this reason, OEMs that offer an over-the-air update feature are best-equipped to efficiently respond to the inevitable next attack.

There is no silver bullet for preventing car theft, but proper implementation of the mitigation methods and practices described above would serve as a strong baseline for averting the vast majority of keyless entry hacking attempts.

---

About the author: Shahar Shechter is Security Researcher at Argus Cyber Security