University of Pisa
Department of Information Engineering
Master of Science in Computer Engineering
HACKING CARS BY MEANS OF
SOFTWARE DEFINED RADIO
Academic Year 2017/2018 Candidate: Daniele Marchetti Supervisors:
Prof. Gianluca Dini
Prof.ssa Cinzia Bernardeschi Ing. Emiliano del Signore
1
Abstract
Cars companies are continuously improving the user’s experience for their customers. One of the aspect on which such companies are focusing, in recent years, is the car’s opening system. They are trying to make the car’s entrance easier, more comfortable and more efficient for users. This goes to the detriment of security. The opening system manages the opening and the closing of the car’s doors and the start of the engine. The key system can be divided into 3 categories: RKE (remote keyless entry system), PKES (passive keyless entry system) and Immobilizers systems.
In this thesis, these categories have been studied in their cybersecurity aspects. In particular, the current known attacks, for each category, are explained. From these attacks, the “Jam and Replay” attack against RKE systems and the relay attack against PKE systems have been chosen to be reproduced and tested on some car models. The objective is to demonstrate that these attacks are actually feasible with a low-cost equipment. The jam and replay attack has been successfully implemented with different low-cost Software Defined Radios (SDRs): rtl-sdr, LimeSdr and HackRF. The behaviour of the SDRs has been coded with GnuRadio and some Python scripts. The attacks have been performed on different car models, in different scenario (residential areas, parking areas, isolated areas) and the have been gathered and analysed, demonstrating that it is possible to open an RKES car. The relay attack has been implemented physically by using two LF antennas linked through a cable. Finally, since the jamming attack is very diffused in public places like Gas stations, a simple application to discover the presence of a possible jammer has been implemented. The objective was to use SDRs and smartphones to build a mobile system able to detect the presence of a constant strong signal at a certain frequency. An android application that uses a Java version of the Hackrf library is presented in the last part of this thesis.
This thesis has been done in collaboration with Direzione centrale per la Polizia stradale, ferroviaria, delle comunicazioni e per i Reparti speciali della Polizia di Stato.
2
Table of contents
1. Introduction... 4
2. RKE system ... 5
2.1 Rolling code ... 5
2.2 RKE differences between implementations ... 8
2.3 RKES attacks ... 10
3. PKE system ... 12
3.1 PKES: opening protocol ... 12
3.2 PKES attacks ... 14
3.3 Relay attack ... 15
4.Immobilizers system... 17
4.1 Atmel immobilizer protocol ... 17
4.2 Attacks against Atmel open source immobilizer protocol ... 19
4.3 Other attacks ... 20 5.Cryptographic algorithms ... 21 5.1 Hitag2 ... 21 5.2 KeeLoq ... 22 6. SDRs ... 23 6.1.1 Hackrf One ... 23 6.1.2 LIME-SDR ... 24 6.1.3 USRP B210 ... 24 6.2 GnuRadio ... 24
6.2.2 GnuRadio-runtime flowgraph changes ... 25
7.Replay attack and Jamming ... 27
7.1 Replay attack with HackRf ... 27
7.2 Jamming attack with HackRf ... 29
8. Jamming and replay ... 30
8.1 How the attack is performed ... 31
8.2 Attack cases ... 33
8.2.1 HackRf One + Dvb rtl-sdr. ... 33
8.2.2 LIME SDR configuration ... 37
8.2.3 USRP B210 configuration ... 39
8.3 Comparison with Samy Kamkar’s RollJam ... 41
3
10. Jam detector ... 44 11. Conclusions... 49 References ... 50
4
1. Introduction
Nowadays modern cars have multiple computers to control the engine, transmission, windows, locks, lights, etc. These computers are called electronic control units (ECU) and communicate with each other over an internal network.
One of those systems is the car key system. The key system is responsible of the opening/closing of car doors and of the lock/unlock of the engine’s start circuit.
Key systems can be divided into 3 categories:
• RKES (Remote Keyless Entry System): the main feature of this category is the use of a key fob provided with a lock/unlock button that the user needs to press in order to open/close car doors within a distance to the vehicle up to 100 meters.
• PKES (Passive Keyless Entry System): these are the most recent systems, no user interaction is necessary in order to obtain the access to the car, given that a valid key is in the proximity of the vehicle
• Immobilizers: passive RFID tag system that locks the engine system unless a valid key is present inside the car.
Every system has some unique characteristics and weaknesses in their protocols, but it is also possible to identify many common weaknesses that can be exploited by hackers in order to gain access to the vehicle and to bypass the immobilizer system.
Next sections will explore the literature and cases of study about known attacks over those kind of systems, by analysing their weaknesses.
5
2. RKE system
RKE system protocol’s main features are:
1. Presence of a button the user needs to press to lock/unlock doors
2. Unidirectional transmission key to car on RF (in Europe 433/868 Mhz): no messages are sent by car to the key fob
3. Works up to 100m distance
RKE systems are implemented in two different ways:
Fixed code: This mechanism was the first one implemented. Nowadays is rarely used and
can be found mostly only in old cars or garage doors, due to obvious weaknesses. In fact, it works by sending a fixed sequence of bit, stored in both the key fob and the car’s receiver. If the car receives a known sequence, it then allows access to the vehicle. This kind of system is the easiest and the cheapest to implement but it has the obvious drawback of being vulnerable to replay attacks. An adversary that records the known sequence is then able to lock/unlock car doors
Rolling code: Nowadays is the most common access system, introduced to prevent replay
attacks. Rolling codes are sequence numbers said to be hardly guessable by attacker (often generated by Pseudo Random Number Generator, PRNG). The sequence number sent by the key fob to the car must be the one the car is expected to receive in order to have access to the vehicle. More details are given in the following section.
2.1 Rolling code
Figure 1-Transmission of a packet from the key fob to the car. The grey part means that an encryption method is being used
6
Two sequences are kept synchronized, one in the key fob and one in the car. Every time the button is pressed on the key fob, the current value of the sequence is sent to the car, the sequence in the key fob is then increased to its next value. Upon receiving a valid rolling code (i.e. the exact value expected, remembering that the two sequences are synchronized) the car increases its own sequence number.
Figure 1 shows the general procedure and packet structure used to communicate to car, to close/open doors, with rolling code mechanism. The payload usually contains: key fob UID, rolling code, action (lock/unlock). This section of the packet is usually encrypted, or it is sent in cleartext but with a MAC (Message Authentication Code) attached. On the other hand, the car stores the current rolling code value associated with the UID of the remote controller from which it expects to receive a message. The association of the remote controller’s UID and the rolling code sequence is done by manufacturers, in a so called “learning mode”. PRNG used in rolling code systems are usually implemented on 40 to 60 bits. However even if the number is huge, it could come to an end sooner or later. In other words, sequence number mechanism is a circular buffer. An important issue to clarify is what will happen if the two sequences lose their synchronization, for example if the user press the button outside of the car range. To avoid a manufacturer intervention, a simple mechanism has been introduced. Car doesn’t store just the current value of the sequence, but the next 16 to 1000 value (according on various reporting of different rolling systems). In this way a sort of validity window is obtained and receiving a value in that window doesn’t lead to a block in the reception of the messages from that key fob.
7
Figure 2 shows a situation where the last received valid message has a counter value A. As there is always the possibility that the transmitter could have been activated several times outside the receiver's range, the receiver must accept values up to some limit (labeled C in the figure). The simple approach of accepting all values larger than the last received value, won't work. The second example in figure 2 clarifies this point by showing a situation in which the rolling sequence is close to the end of its period, in fact A is close to the upper end of the counter value range (the dark segment from point A to C shows the window of acceptance for counter values). Point B is an example of a value that would be accepted while point D is a value that would be rejected. When a value is accepted, the window starting point moves to that point.
This scheme ensures that old messages are never accepted unless the head of the rolling window has reached the old counter values. By choosing a large enough counter span and limiting the window size itself, this scheme effectively prevents replay attacks with old messages.
Whenever a packet from a key fob is received by a car implementing a rolling code system, the following steps are performed:
1.If UID is valid then
2.1 If cntkey<cntcar ? an old message is received
2.2If cntkey<cntcar -Thdown? then block any other message from that key fob
Else reject action
2.3 Else if cntkey>cntcar + Thup then value out of validity window, reject action
2.4 Else valid message, sequence counter increased 3. else Abort
Where cntkey is used to represent the value of the sequence counter stored in the key fob
and cntcar instead is the value of the sequence stored in the car. Thdown is a threshold value
that some manufacturers use (in [1] it has been found that VW cars use this threshold with a value of 2). Thup is the threshold that defines the span of the validity window.
8
From this scheme, it is possible to notice that a sort of DoS attack can be performer by an attacker by sending intentionally messages older than cntcar -Thdown
2.2 RKE differences between implementations
As illustrated in the study conducted by Flavio D. Garcia and David Oswald [1], we can identify some differences between several implementations of the rolling code scheme. For the VW group (millions of vehicles worldwide) these differences in the protocol can be grouped in 4 different set of cars. Every set is different in some of 4 features: format of the packet sent by the key fob, modulation scheme, authentication (i.e. if MAC is used or if authentication is given by a correct decryption of the packet) and, finally, cryptographic algorithm used. Every group is indicated with VW-x, x ∈ [1,4].
In the format of the packets, the numbers are intended as bits used for every field; implicit authentication is intended as the usage of encryption with shared keys and explicit authentication, on the other hand, refers to the usage of a MAC.
VW-1:
Format:
UID is the unique identifier of the remote controller, lsfr( linear shift register) is the value used as rolling code and finally btn is the action performed.
Modulation: On-Off-Keying (OOK) a 433.92 MHz, pulse-width coding con bitrate 0.667 kBit/s
Authentication: implicit
Crypto: this scheme doesn’t use a cryptographic key, even if in the figure the uid and rolling code field are represented in grey, actually it is not a true encrytion, this scheme is in fact only based on “obscurity” .
9
Format:
These cars use a secure cryptographic algorithm to encrypt the fields represented in grey. These fileds contains the id of the key fob, the rolling code value and the action performed.
Modulation: OOK at 434.4MHz, Manchester-encoded data using a bitrate of 1 kBit/s. Authentication: implicit
Crypto: proprietary block cipher AUT64, (used also for some immobilizers schemes) it has a security level above 80
VW-4:
Format:
This packet format is very similar to the one of the VW-2 and 3, just some differences in the start preamble.
Modulation: OOK a 434.4MHz,Manchester-encoded data con bitrate 1.667 kBit/s. Authentication: implicit
Crypto: block cipher XTEA, no feasible attack known against this cipher in the context of RKES
Even if the groups 2,3 and 4 employs strong cryptographic algorithms, a serious implementation mistake has been found for the cars of these groups. In fact, for each group, the same crypto key has been used for every vehicle sold to customers. It means that the same key is used almost worldwide for the same group of vehicles, and due to the fact that this key is stored in the ecu of both the key fob and the car key system, it is possible to obtain the key through reverse engineering of the firmware and then clone the key fob.
10
A different scheme that is based on explicit authentication, i.e the use of a MAC, used in serveral vehices worldwide, is the Hitag2 scheme. Hitag2 is a cryptographic scheme largely used in rolling code systems, garage opening systems and immobilizers, but it has some weaknesses already studied in literature. Some updates of the algorithm have been already released (for example Hitag-128 that is based on AES-128) . The features of the rolling code scheme of cars using the Hitag2 algorithm are:
Format:
UID is a 32-bit identifier; btn is a 4-bit button identifier; lctr are the 10 least-significant bits of a 2bit counter ctr; ks are 32-bits of keystream, i.e. the MAC, and chk is an 8-bit checksum. Apart of the attacched MAC, that is computed with a secret key, the rest of the packet fileds are sent in cleartext.
Authentication: explicit
Crypto: Hitag2 is a stream cipher widely used in millions of vehicles and it is vulnerable to several attacks. It cannot be considered secure.
Obviously the main weakness for vehicles that use this scheme is given by the cryptographic algorithm itself.
2.3 RKES attacks
There are several attacks known in literature against rke systems:
1. Bruteforce/cryptoanalytic: these kind of attacks can be performed if weak crypto algorithms are used, this is, for example, the case of Hitag2;
2. Reversing the car bus: this attack in fully described in [3] and allows the attacker to simulate a button pressed, but it requires physical access to the CAN bus of the car; 3. Replay: replay attacks consist in re-using an old message to perform the open action.
11
scheme, on the other hand, are vulnerable to these kind of attacks. An attacker with an old “opening” packet can gain access to the car whenever he wants;
4. Jamming: a jamming attack is very easy to perform nowday, it consists in sending a strong signal on the same frequency window of the car in order to disturb the communication signal from the key fob. This leads into a packet that never reaches the car. However every modern car mounts a light/sound system that is triggered when an action from the key fob is received, so it can be difficult to simply jam the signal, however it is still possible to combine replay attack and jamming;
5. Jamming&replay: this attack consists of jamming two consecutive signal from the key fob while concurrently storing them and use them as follow:
When the user approaches the car and press the button on the key fob to unlock the door, the signal will be jammed and recorded,in order to prevent the car for hearing it. As the user doesn’t get the feedback from the car ( through lights and sounds) he will press the button again. The attacker repeats the previous procedure of jamming and recording on this second signal. This time the attacker replays the first signal. At this point the attacker has a valid packet,i.e. a packet with a rollling code that the car will accept.
However there are still some issues. In fact the packet that the user has got is a “opening” packet. The attacker will have to jam the key fob when the user will leave the car and force him to close the vehicle mechanically. Otherwise the jamming and replay could be applied also on the “closing” signal, but there are some issue even in this case. Many schemes let the field that contains the open/close action be in cleartext, so a simple manipulation of the action field is needed in order to provide acces to the car. On the other hand, if the action is included in the encrypted part of the packet, (most recent systems do this), it can be almost impossible to manipulate the packet easily; excepts for some particular weaknesses of the crypto protocol that can be exploited (i.e. bit flipping attack if no mac is used).
12
3. PKE system
PKES or Passive Keyless Entry Systems are the most recent key systems implemented in cars. These systems include the door opening system but also the start system (sometimes they are called PEPS system, i.e. Passive Entry and Passive Start system). The main features are:
1. No action is needed by user (no need to press any button) to get the access of the car: the authentication protocol is triggered when the user is approacing his car so that when the hanlde is polled the door will open
2. A distance no longer than 2 meters is required to unlock the doors 3. To be able to start the engine the key must be inside the vehicle
Figure 3- Pkes regions
Due to these features it is possible to identify 3 different areas:
1. Outside area: if the key is in this area the authentication protocol can be started 2. Inside area: in this area it is possible to unlcok the engine, if the user press the start
button inside the car the engine will activate itself
3. Remote area: key fob are usually provided also with a button, in the remote area, up to 100 m it is possible to use the button to open/close the doors.
The localization of the key in these areas is done with RSSI, the accuracy is dependent of the single implementation.
3.1 PKES: opening protocol
Two type of authentication protocol based on challenge-response are known to be used by pke systems: uni-direction and bi-directional. The first one in mostly used in the open/close
Passive Entry Passive Start RSSI based localization
13
protocol due to the fact it is the faster, the second one is mostly used for the immobilizer protocol (the engine start protocol).
The uni-directional scheme can be schematically represented by figure 3.
Car sends periodically beacons to detect the presence of the key (the same beacon mechanism is triggered when the handle is pulled).
In uni-directional systems, the vehicle authenticates the key fob. The vehicle generates a random number (Nonce) and transmits it via LF, as challenge, to the key fob. The key fob encrypts the challenge and returns that via RF as response to the vehicle. The vehicle does the same and encrypts the nonce. If the encrypted nonce and the received response are identical, the key is authenticated, and the door unlocks.
The bi-directional procedure offers increased security compared to uni-directional authentication. The key fob authenticates the vehicle before replying and, subsequently, the vehicle authenticates the fob. Both steps use different secret keys. The vehicle generates a
1. Periodic scan (LF)
2. Ack proximity (UHF)
4.Key response (UHF) 3.Car ID || Challenge (LF)
LF (120 – 135 KHz), (1-2 meters), (RFID tag)
UHF (315 – 433 MHz), (50-100 meters)
14
nonce, encrypts it using secret key1 (let’s indicate the encrypted nonce as *Nonce*), and sends both via LF to the key fob along with a command to indicate that bidirectional authentication is used. The fob encrypts the Nonce with secret key1 and compares it to *Nonce*. If both are identical the vehicle is authenticated to the key fob.
Then, the key encrypts this first encryption result by using secret key 2 and sends it as response via RF to the vehicle. The vehicle performs the same procedure and compares its own result with the received response. If these are identical, the key fob is authenticated to the vehicle, and the doors unlock, or the vehicle starts.
As illustrated in figure 4, the communication from car to the key fob is done on LF while messages from the key fob are sent via UHF. The reason is that the key fob in passive system also acts as rke system, so it is necessary assuring a coverage area that with LF cannot be reached.
3.2 PKES attacks
PKES systems are typically challenge-response based so this mechanism itself is sufficient to prevent replay attacks, however other attacks are feasible and some of them has been already seen in rke systems:
1. Bruteforce/cryptanayltic attack: feasible when weak crypto is used
2. Dictionary: if there is no authentication in the sender (or simply the uid is sent in clear), it becomes possible to collect several responses from the key fob and build a dictionary by simply pretend to be a receiver (a car) and query the key fob. Then a true session will be started with the car, and a look up in the dictionary will be performed to find out if the response for the car challenge is already in the dictionary. 3. Forward prediction: if weak PRNG are used it is possible to predict the challenge of
15
3.3 Relay attack
Relay attacks against pkes can be easily performed even with a cheap set up. The problem in pkes is that the idea of proximity of the key fob to the car is translated with the possibility to communicate with the key fob itself. Based on this idea, if an attacker can create a “bridge” connecting the car to the valid key fob, he will be able to get access as authenticated user. There are two possible implementations of this attack as described in [6], the first one is the cheapest and it is the relay attack over cable:
Figure 5- Relay over cable
The idea of this attack is to use two antennas connected via cable to create a bridge from the car to the key fob. If the distance from the car is within 100 meters, due to the fact that the answer from the key fob is sent through UHF, it is sufficient to relay only the signal from the car (LF signal). An attack of this type can be prepared with a budget of just 40€.
An even more powerful attack is the relay over the air, that allows the attacker to cover distances up to thousands of meters. The following figure represents the scheme:
16
The idea here is to modulate the signal up to 2.4 Ghz and demodulate it again to 130Khz when in proximity of the key fob and vice versa.
The power of the relay attack is that it is completely independent from the model, the protocol or the cryptography used. The limit of this attack is just the time it takes to be performed. In fact, the authentication protocol has a timeout, and if, for some reason, the attack takes too long to bring the answer from the key fob to the car, the attack will fail. The main reason of a fail due to timeout is the distance: for example, an attack over cable must deal with the fact that the wave propagation in the cable is 66% the propagation over the air. However different car models have different timeouts (crypto, processing…), it means a different maximum distance at which the attack will still be feasible. A review taken from [6], for 10 different cars is provided in figure 7.
Looking at figure 7, it appears that theoretically the range of a feasible relay attack goes from 10 (model 10 with 35 us of delay accepted) to 3000Km.
Figure 7-Max delay allowed for relay attack and key response and time spread [6]
17
4.Immobilizers system
The idea of the immobilizer system is that even if someone breaks into the car, without a valid key, he cannot start the engine.
Immobilizers works with RFID tags and readers (120 a 130 kHz) in distances of the order of cm, communication are done over LF. They usually use a challenge-response protocol, sharing a cryptographic key between the key fob and the car.
There are several implementations in the market, some of the differences between immobilizers system can be found on:
1. Crypto algorithm used 2. Commands available
3. Active or passive mode: it means the use of a battery or inductive coupling to harvest the energy required to communicate
An interesting case of study, that shows that weaknesses can be found even if strong cryptography is used, is the open source immobilizer protocol developed by Atmel
4.1 Atmel immobilizer protocol
As reported in [8], the features of this protocol are: • Communication over LF (125kHz)
Cryptography based on AES-128 Commands:
18
◦ Read key UID and error status ◦ Init authentication
◦ Set secret key
◦ Init/leave enhanced mode ◦ Repeat last response
◦ R/w user memory, set access protection memory
The protocol is a bi-lateral authentication protocol and works as already described in the section 2.3. Figure 9 represents the temporal order of actions during a bilateral authentication.
It must be noticed that the UID is always sent in cleartext. Upon receiving a valid UID the car starts the AES encryption with key1 and sends to the key fob the encrypted nonce along with the nonce itself (figure 9 shows that actually not all the bits of the encrypted nonce are sent, but just M<=N bits)
The key receives the two values, encrypts randN and check if it is the same as randM. If it is the case, the key fob will use the output of the first encryption as input to a second encryption with key2. The output of this second encryption is sent to the car that will have
19
already encrypted with key2 its output from the first encryption and is now ready to check the two values. If the check succeeds the authentication is valid.
4.2 Attacks against Atmel open source immobilizer protocol
The implementation of many of those commands leads to some vulnerabilities that can be exploited to perform attacks to the protocol, as presented in [8]:
1. Relay: as a challenge-response protocol, it is subject to relay attack. Furthermore, the command “repeat Last Response” can be exploited to gain extra time by simply sending a false crc error message to the car
2. Tracking: due to the fact that the uid is sent in cleartext without any form of authentication, it is possible to query the key fob arbitrarily and receive the answer containing the uid. This allows a sort of tracking of the user position
3. Dos:
Figure 10- DoS attack
The protocol has a weakness in the implementation of the key distribution system: in fact, no integrity check is added in the above schema, leading to the possibility for an attacker to continuously overwrite the cryptographic key (without knowing the value that will be overwritten) in the key fob. This could lead also to unexpected behaviour of the car, if performed while the user is driving.
20
4. Replay: since no mutual authentication is provided (only the key fob is authenticated to the car) an attacker can pretend to be the car associated with the key fob using the following scheme of actions:
Figure 11- Replay attack
At this point the attacker has access to some privileged commands as “Read/Write user memory” in the key fob.
4.3 Other attacks
Immobilizers protocols are also vulnerable to other type of attack, but it is important to point out that (most of the) attacks on immobilizer chips become feasible after the access to the vehicle has been gained:
1. Crypto/bruteforce: if weak crypto is used
2. Removing of the chip: immobilizer chips can be physically removed and substituted with a so called “immo emulator” having the car working as almost normal.
3. Pulling the Response Codes from Memory: key’s response can be found in the memory of the immobilizer but access to the car must be gained no longer than few minutes after the response has been received.
21
5.Cryptographic algorithms
As already stated in previous sections, lots of vehicles still use weak cryptographic protocols in the exchange of messages between key fobs and cars. The main reason for this depends on the decision of the car manufacturers to use proprietary algorithms, hence not tested by the community. This leads to the extension of the attack surface, introducing the possibility for an attacker to exploit the weaknesses of the specific algorithm, break it and get the content of the messages.
The next sections aim to briefly expose the features and weaknesses of two of the most diffused algorithms: Hitag2 and Keeloq.
5.1 Hitag2
Hitag was introduced in 1996 and has evolved through different versions, the last one is Hitag-128 that exploits the well known AES-128, with all the benefits in terms of security granted by the use of a secure and well tested scheme. However, Hitag2 has been used for years and still today it is possible to find it in many vehicles, both in the access and in the immobilizer system. Example of manufacturers known to have adopted Hitag2 are: Audi, Bentley, BMW, Chrysler, Land Rover, Mercedes, Porsche, Saab, Volkswagen, and many others.
Hitag2 has 3 operating modes: ◦ Public
◦ Password (authentication through the Exchange of a password, in cleartext) ◦ Crypto
It has a 48-bit key (Hitag1 uses only 32-bit key), so a not sufficiently high number of bits, considering the computation power of nowadays computers. This cypher has been widely studied and many weaknesses have been found, the next table reports just a fraction of the attacks to this cipher:
22
As it can be seen in figure 12, there are two attacks feasible, even without a dedicated device. However, the cryptanalytic attack that requires 6 minutes, requires also 136 messages, practically unfeasible in the context of rke systems.
5.2 KeeLoq
Keeloq is an algorithm created in Mid-1980s by Manufacturer Nanoteq and used in vehicles like: Chrysler, Daewoo, Fiat, General Motor, Honda, Jaguar, Toyota, Volkswagen, Volvo.Some features are:
• Block cipher with a key length of 64 bits
• Usable in both rolling code (RKE) and challenge-response (immobilizer) systems • Every user receives from manufacturer a key that will be stored in all the associated
devices (Kman, represents the default key).
• Learning mode (implemented in the receiver): Kdev=f(Kman,ID) , f=decryption and ID= id of the device, this function is used to derive the shared key ( shared by key fob and car receiver)
Since the introduction in the market there were many studies on the cipher, and a synthesis of the main attacks discovered is presented here:
Mathematical analysis: the most efficient attack in this category has a complexity of 2^48 and requires 2^16 couples plaintext-ciphertext
Power analysis: hardware implementation of attacks of this category can obtain both Kdev and Kman. In software implementations there is a successful SPA attack [1] Most recent dedicated FPGA clusters make feasible even a bruteforce attack
Figure 12- Attacks on Hitag2: for every attack the namber of messages to be sniffed(traces) and the time are provided [2]
23
6. SDRs
All the attacks presented in the next chapters, have been implemented by means of Software Defined Radio (SDR). SDRs are systems where components that have been traditionally implemented in hardware ( mixers, filters, amplifiers, modulators/demodulators, detectors, etc.) are instead implemented by means of software on a personal computer. Three SDRs have been used and their main features are presented in the next chapters.
6.1.1 Hackrf One
The main features of HackRf are:
1 MHz to 6 GHz operating frequency half-duplex transceiver
up to 20 million samples per second
8-bit quadrature samples (8-bit I and 8-bit Q)
software-configurable RX and TX gain and baseband filter software-controlled antenna port power (50 mA at 3.3 V) SMA female antenna connector
SMA female clock input and output for synchronization USB-powered
open source hardware
By observing the list above, it is important to make the following considerations:
• For RKE systems, the range of frequency operativity of HackRf One is more than sufficient: as illustrated in the previous sections, RKE systems operate at 433/868 MHz in Europe. On the other hand, if the intent consists in implementing, for example, a software-based relay attack against a PKE system, HackRf becomes unsuitable. In fact, messages are sent from the car to the key in LF (125 Khz), far away from the boundary of operating frequency of this SDR.
• HackRf is half duplex, this means that it cannot receive and send at the same time. This is not a problem for a replay attack, that is not bounded by any timeout, or a jamming.
24
6.1.2 LIME-SDR
Some features of this full-duplex SDR are:
RF Transceiver: Lime Microsystems LMS7002M MIMO FPRF
FPGA: Altera Cyclone IV EP4CE40F23 - also compatible with EP4CE30F23 Memory: 256 MBytes DDR2 SDRAM
USB 3.0 controller: Cypress USB 3.0 CYUSB3014-BZXC Frequency range: 100 kHz – 3.8 GHz
Bandwidth: 61.44 MHz
RF connection: 10 U.FL connectors (6 RX, 4 TX) Power Output (CW): up to 10 dBm
Multiplexing: 2x2 MIMO
With this full duplex SDR it is possible to implement even a jamming and replay attack using only this piece of hardware. Furthermore, the frequency range allows this SDR to read also LF signals, like the ones used in PKE system.
6.1.3 USRP B210
2 TX & 2 RX, Full Duplex
Fully-coherent 2x2 MIMO capability Xilinx Spartan 6 XC6SLX150 FPGA
Up to 56 MHz of instantaneous bandwidth in 1x1 Up to 30.72 MHz of instantaneous bandwidth in 2x2 GPIO capability
This SDR is the most expensive one used during this study. It is full duplex and characterized by high precision than the other SDR described above.
6.2 GnuRadio
Gnuradio is an open source software development toolkit for programming SDRs. Gnuradio Companion uses a graphical interface to develop the desired behaviour. Programmers must
25
drag and drop blocks from the library and connect them together to obtain the features wanted. This kind of drawing is called flowgraph. The blocks are then converted into Python code and loaded in the SDR when the flowgraph is executed. Gnuradio companion allows programmer to see the python code, to let them change it and giving this way to the application more flexibility than using just blocks alone.
Blocks are provided with lots of parameters that the developer can change arbitrarily.
Figure 13- An example of blocks connection in a gnuradio’s flowgraph
A block can be filled with one or more input signals, these signals may be outputs from other blocks. In order to be executed, all the blocks in the flowgraph will be contained in a so called “top_block”. Every application needs a top_block to be able to run.
Manipulating the python code allows the developer to switch at runtime, for example, from a top-block to another one that codes a different behaviour for the SDR.
6.2.2 GnuRadio-runtime flowgraph changes
Modifying the Python code generated from a flowgraph may be useful in implementing some features in the SDR behaviour, however some changes could be very slow due to the nature of Gnuradio’s blocks.
Change top_block: to be able to switch between top_blocks implementing differences
features for the SDR some steps are necessary:
1. Call lock() on the top_block instance that is running 2. Disconnect all blocks from the running top_block 3. Call unlock()
26
4. Stop the execution with the command stop 5. Load and start the new top_block
Block parameters: it’s not possible to operate directly on the reference of a block’s attribute
without the risk of a crash. If we have to modify a parameter’s value at runtime, it is suggested to define a variable in the gnuradio-companion flowgraph. When the code is generated from the flowgraph, there will be getter/setter method to safely change the value.
Closing a file being written: if during the execution we are writing into a file, for example
recording a signal, and we need to close that file and start writing into a new one, we must change the file name at runtime by using a variable. This will close the first file.
27
7.Replay attack and Jamming
The study begins with some replay attack tests. This kind of attack is successful only against cars that use a fixed code scheme. The idea behind this attack is very simple, it consists of two phases: in the first one, the adversary records the “Open” command signal while in the second one he replays the command to gain access to the car.
Nowadays only few cars still implement this mechanism, due to the fact that it has been substituted by rolling code scheme since early 2000’. However, it can still be found in a considerable quantity of products in the industry of anti-thief home system and automatic doors.
Another way to attack a key fob signal consists in jamming it by sending a strong “trash” signal at the receiver’s frequency. In this way the receiver can’t listen to the valid signal. To perform a Jamming attack, we only need to record some kind of signal or generate one by ourselves. This signal must be sent at the receiver’s frequency. For example, if we jam a “Close” signal and the user doesn’t pay enough attention to the sounds/lights that the car usually emits when a signal is received, the attacker is able to access the car as soon as the user leaves.
7.1 Replay attack with HackRf
The behaviours that we desire for a replay attack are: record in a file a signal, captured at a certain frequency and then transmit the record (from the audio file) to a certain frequency with an arbitrary gain (but high enough to reach the receiver). First, we need a valid signal from the key fob, and possibly an “Open” one, to avoid any manipulation on the signal itself. In Gnuradio we prepare this flowgraph:
28
Figure 14- Receive and store flowgraphs
Variable blocks are just variables that we can use in other block’s parameters, changing the value in the variable block will have effects everywhere a variable with the same name appears as a parameter. A variable value could be any python expression.
Inside the Osmocom source block is possible to select the frequency at which we would like to listen to a signal (Ch0 Frequency). There are 3 different gain parameters that we can change: RF,IF,BB gain.
The WxGUI FTT block makes Gnuradio plot a dynamic graph on the screen, to see the signal at the band we have previously set. Finally, the File sink block allows the application to store on the hard disk, in a file (at the path indicated), the signal received. The application starts recording the signal as soon as it is executed, the file will have hundreds of MB even for just a few seconds of recording. Once obtained a valid “Open” signals, we can send it to the receiver with the following flowgraphs:
29
The scheme is specular to the previous one: the signal is taken from the audio file through the Source block, then sent at the same frequency with the Osmocom Sink block.
If the system uses fixed codes, the message we send will be considered valid. Performing this attack is very easy but nowadays only few systems in car’s industry are vulnerable.
7.2 Jamming attack with HackRf
To jam a signal from the key fob, the Software defined radio has to be placed in the proximity of the victim’s car. The blocks used to program the SDR are the same used in the replay attack to send a signal out. Once the desired frequency has been set, we have to increment the gain at a level that is sufficient to completely obscure the valid signal. The signal that was sent out in the test cases was a signal recorded from an FM radio frequency chosen randomly (98.9 Mhz) but it could have also been generated with Gnuradio itself. In case the signal is taken from a source file block, It is important to set the “repeat” to reproduce a continuous jammer behaviour.
30
8. Jamming and replay
A jamming and replay attack can be performed against every kind of vehicle that implements a rolling code system. The main idea of this attack is to obtain a signal with a valid rolling code.
A summary of the attack is represented in Figure 16:
Figure 16- Jam & Replay scheme: signal A is immediately sent as soon as signal B is stored on the attacker device. Signal B is the valid signal that can be used to have access to the vehicle
Let’s assume the user is trying to open his own car with signal A: the attacker will jam this signal to prevent the car from hearing it and concurrently he will store signal A on his Jam & Replay device. As the user is not able to open his car at the first try, he will press again the open button on his key fob. At this point the attacker is going to repeat the same operations one time more, but with a difference: after having jammed on signal B and having stored it on the device, he will send to the car signal A, allowing the victim to get access to the car. Now the attacker has a valid “open” signal, signal B, that can be used to gain access to the vehicle.
The attack continues with the following steps: 1. The attacker follows the user
2. As soon as the user gets off his car, the attacker starts jamming on the user’s key fob frequency, to force him to close the car mechanically.
31
3. Now the attacker can use signal B (i.e. the signal with a valid rolling code that the car has not already received) to access the vehicle.
This attack can be performed also to obtain a “close” signal. In that case however, the attacker needs to modify the signal to change the command into an “open” one. This operation however can be very difficult to be performed, dependently on the cryptography the car is implementing. According to [1] there are still many cars that do not encrypt the command field, allowing an attacker to easily change it. However, if a car encrypts even that field, and uses a strong encryption algorithm, it could be impossible for an attacker to change it in time (before the user sends a new signal to the car), making the signal previously obtained unusable.
8.1 How the attack is performed
The idea of this attack is to prevent the car from receiving any signal and concurrently store them, i.e. jam the signals and store them without the jammer’s interreference. To do this, the attacker must include a phase of study of the victim’s key fob signal, to set his receiver and the jammer frequencies properly. In fact, the attacker must set the jammer signal at a frequency sufficiently distant from the original signal but still in the range of the car’s receiving window. The attacker jams the signal by putting a sort of “trash signal” into the valid one, in this way the car will discard the key fob signal when it is received. On the other hand, the attacker must set a proper low pass filter to receive only the valid signal and discard the jammer.
In this setting phase, the attacker must perform the following actions: 1. Record a signal from the victim’s key fob
2. Find the bandwidth and exact frequency of the signal’s peak 3. Set jammer, receiver and filter’s parameter
The last point may need some time: once obtained the information in point 2, a simple jamming signal must be generated: the attacker will then take note about the width of the jamming signal.
32
Now the receiver frequency will be set at the key fob signal’s peak frequency. With some simple math the attacker calculates the filter cut off and transition width and the jammer carrier frequency: the cut off frequency needs to be wide enough to not cut away any information from the signal. The transition width is defined as the width from the edge of the passband to the edge of the stopband. Dependently on the hardware used, very low values of this parameter may be not allowed (for example 1k). However, in most of the cases we can just fix a value, as for example 10k and adjust only the cut off parameter. The jammer should be set at a frequency on the right side of the spectrum, with respect to the transition width, to be sure that the attacker’s receiver won’t read the jammer after the filtering and allowing some additional bandwidth in case the gain of the jammer signal must be raised. Suppose the victim’s key fob signal is centred at 433.93 Mhz and the signal has a bandwidth of 50 Khz. The attacker can set a filter with a cut-off of at least 25 Khz centred at 433.93Mhz, and with a transition width of 10 Khz. This means that any part of the signal up to 433.955 Mhz is not affected by the filter. Considering the bandwidth of the peak, this filter is sufficient to include every information the signal contains. At 433.965 Mhz the power of the signals is halved (transition width equal to 10k). If the jammer signal has, for example, a bandwidth of 10Khz, then a possible frequency to centre the jammer can then be 433.975 Mhz. Having some extra time to make tests on the victim’s clean signal, the attacker can find its exact bandwidth. This makes him able to set the jamming signal as far as possible from the victim’s signal, in the frequency spectrum.
33
8.2 Attack cases
The attack was performed with some SDRs. The behaviour was programmed with Python and Gnuradio. The first configuration tested is:
8.2.1 HackRf One + Dvb rtl-sdr.
Configuration cost: ~ 300€
Figure 18- HackRf (on the left) and rtl-sdr
Gnuradio Flowgraph:
Figure 19- Jam and replay flowgraph with HackRf and rtl-sdr
Figure 19 shows the flowgraph used in this configuration, there are some components used also in the other configurations (with different parameters values). The main blocks are: Osmocom source: this block is used by the rtl-sdr and contains all the receiver’s parameters. The frequency at which the device must listen to and the gain. Rtl-sdr due to strong hardware limitation can use only the RF gain.
34
Osmocom sink: This block is used by HackRF and contains all the transmitter’s parameters. The frequency is initially set, through a variable, at the jammer frequency. In runtime the variable will be changed into the same value as the receiver, to send the first valid signal recorded to the victim’s car. Higher the gain higher the noise level read by the rtl-sdr will be, so we need to be careful when setting gain to a very high value.
Low pass filter: this block contains all the parameters needed to set the filter. The filter must discard the jammer effects, to be able to record a clean signal. The cut-off and transition width are applied based on the frequencies set in source block that is linked to the input port of this block.
Selector: this block selects between two or more input/output. Setting the in/out through the value of a variable allows us to change it in runtime when it is needed.
Probe level: this block allows us to read the output value from a block, using the proper function in Python.
Python Code:
The flowgraph alone is not able to switch input/output or to detect and count how many signals we have received. The full behaviour of the jam&replay attack must be programmed in Python, starting from the code generated by Gnuradio. Inside the main() it has been added a while loop. Within the latter, the value (i.e. the magnitude of the signal after the filtering) given from the probe level block, by means of the function level(),is continuously checked. When this value is above a threshold (Th), it means that a peak is being received. A counter variable (counter) is used to count the number of peaks received and to separate the behaviour in case we are receiving the first or the second signal from the key fob. In the former, we must change the file in which we are recording, and this is done through the variable that selects the output of the selector block (in the code: set_output_file(1)). In this way we have two separate files containing the signals received from the key fob. In the latter we must change the input to the sink block, in this way the jammer is stopped, and we can transmit the first signal recorded. If the jammer’s frequency is such that a signal centred at that frequency makes itself unhearable by the car, we must also change this value through the proper variable; in the code this is done with the function set_jam_freq() that will change
35
the value of the variable we used to store the frequency for the transmission block (osmocom sink block). The threshold is set by an algorithm that works this way: it monitors the environment at the receiver frequency for a certain amount of time and collects values of magnitudes. These values are then sorted, and the mean value of the highest ones is then computed. This value is then multiplied by a constant of 1.35, found after some tests. The power of the attack in this configuration is strongly limited by the hardware of the rtl-sdr. The signal may not be received with enough strength to ignore the disturbance caused by other signals, that can act in this case as “jammers”, making the recorded signal not usable. Furthermore, at a distance above 5 meters, depending on how much noise we have, the attack cannot be performed, because the strength at which the valid signal is received by the rtl-sdr is as low as the noise, so it will not reach the threshold. Reducing the threshold would only have the effect of triggering the algorithm just by receiving noise signals.
36
However, this very low-cost configuration can be set to perform the attack successfully in environment not very noisy (low density residential area) within an acceptable distance (5 meters). The ideal situation for an attacker is to sit in a car just next to the victim’s car.
Test cases: Test case Freq receiver (Mhz) Freq jammer (Mhz) Filter cut-off (Khz) Max
distance Gain Threshold
Model 1 433.905 433.99 30 [4m,5.5m] [45,50] [0.3, 1.2] Model 2 433.885 433.995 55 Model 3 433.91 434.991 41 Model 4 433.886 433.93 30 Model5 433.881 433.955 45 Model 6 433.877 433.93 35 Model 7 433.883 434.1 55 Model 8 433.903 434 60 Model9 433.893 433.968 Sin1:378 Sin2:-338 330 400 Model 10 433.92 433.95 35
The table above collects the results of the tests on 10 different cars models. These models were of different companies and different production years (from 2003 to 2017).
Threshold is the minimum needed to detect the signal from the key fob and trig the attack; more the noise higher the threshold. The max distance and the gain filed report the range of
37
the max distance allowed between the attackers and the car and the relative gain values used to successfully perform the attack.
Some observations:
The differences in the filter’s cut off depends on the bandwidth of the signals. Two types of signal were observed: one with a single peak and another with a double peak. The latter are associated, in the previous table, with a bigger cut off. Cut offs between 30k and 40k instead, are associated with a single peak signal.
Model 6 in the table shows something not present in the other test cases. This RKE implements a sort of hopping mechanism, the frequency of the signal switches between two different frequencies at every push of the key buttons. To perform the attack in this case, it was needed to add two sinusoidal signals at different frequency (in the table these are Sin1 and Sin2) so to have a jamming action on both the frequencies used by the system.
A case not reported in the table above had shown a mechanism that makes the attacks slightly more difficult. This model in fact, sends from the key fob 3 peaks, at different frequencies and at different times. If a jamming is conducted on just one of these peaks, the car will still receive the command from the key fob correctly. To jam & replay this model, a concurrent triple jam at the 3 frequencies used must be performed, in addition 2 passband filters must be applied to recover the 3 peaks without the jammer interference.
8.2.2 LIME SDR configuration
Configuration cost: ~ 400€
Lime-SDR is a full-duplex SDR with a range of frequency between: 100Khz and 3.8Ghz
38
Lime SDR needs some packets to be installed, providing specific blocks to be used with Gnuradio. The flowgraphs now looks like the following figure:
Figure 23-Lime sdr flowgraph
The range of the gain is limited within 0-60dB in transmission. Here is it possible to set even some filters (analog and/or digital).
Apart from the transmission and receiver block, the flowgraph is the same as the one used before. For every car it is necessary to set the parameters: frequencies, cut off and gain. The threshold is again found by monitoring at the receiver frequency before starting the attack.
39
Test cases:
Test case Freq receiver (Mhz) Freq jammer (Mhz) Distance Gain Jammer Threshold
Model 1 433.93e6 433.992e6
<2m [57,60] [0.015,0.03] Model 2 433.92e6 434.12e6
Model 3 433.94e6 434.055e6 Model 4 433.910e6 433.956e6 Model 5 433.92e6 433.98e6 Model 6 433.898e6 433.957e6
These tests have been performed with the same first 6 models of the previous configuration. The filter’s cut off has not been reported because it has remained unchanged.
The experiment shows the limit of this SDR in performing the attack: the attacker must be no more than 2 meters away from the victim’s car. It must be specified that the antennas used were the ones provided with the SDR and are better suited for frequencies above 800Mhz. Another limit discovered during the tests depends on the software. The Gnuradio’s Lime blocks, provided from the community, are not able to change the frequency of transmission/receiver at runtime via the getter/setter method. So, at the moment, the attack with lime-sdr requires a little more effort to find a frequency that allows both the jamming and the transmission of the recorded signal.
8.2.3 USRP B210 configuration
Configuration cost: ~ 1200€
40
Figure 24- USRP b210
Even in this case we need to install extra packets for Gnuradio (depending of the software version installed on the pc) to use specific blocks with this SDR. UHD sink and source must be used, but with some USRP models even osmocom blocks should work.
Figure 25-USRP flowgraph
Usrp has proven to be the most efficient and stable SDR between the ones used for these experiments, here are the result for a model tested:
Test case Freq receiver (Mhz)
Freq jammer (Mhz)
Threshold Distance Gain
41
8.3 Comparison with Samy Kamkar’s RollJam
As presented during DEFCON 23, Samy Kamkar has developed a device, called RollJam [4] that implements the Jam and Replay attack. The purpose was the same of this thesis: proving that with a low-cost configuration it is possible to perform a Jam and Replay attack against an RKE system.
Samy Kamkar device is made by 3 components: • One Teensy 3.1
• Two CC1101 transceiver The total cost is ~50€.
Figure 26- Samy Kamkar's RollJam device
CC1101 has circuits mainly intended for the ISM (Industrial, Scientific and Medical) and SRD (Short Range Device) frequency bands at 315, 433, 868, and 915 MHz.
Teensy 3.1 is an USB development board that can be programmed with the Arduino IDE. The hardware is strongly limited in performance but is still suitable for this kind of attack, in fact the frequency range covers the ones used by RKE systems. An SDR like HackRf has benefits in terms of performance and support by the community of the main tools used to program SDRs, like Gnuradio, but it is more expensive.
We can state that the RollJam configuration is the less expensive one that is able to perform the Jam & Replay attack. Samy Kamkar has still not released the code or any report about test cases, so any detailed comparisons with the attack developed in this thesis are not possible at the moment. At DEFCON 23 Samy Kamkar stated that the RollJam was tested
42
against RKE systems, to obtain a valid “Closing” signal. The signal has been then modified to obtain an “Opening” signal, thanks to some of the weaknesses in the encryption, like the ones showed in chapter 2. In this thesis the aspects concerning the signal manipulation have not been considered and the attack has been performed in a different way, as showed in the previous paragraphs; the differences are: 1) we record and use only opening signals 2) we replace the signal manipulation phase with a jamming on the victim’s closing signal to force him using the mechanical closing and gaining this way the access, by sending the valid “opening” signal previously captured.
43
9. Relay attack via cable
The idea behind a relay attack is building “a bridge” for the signals between the PKES car and the key fob. The basic assumption which we are going to exploit is that if the car hears the key, then the key is close to the car. This kind of attack can be implemented via cable or via air as showed in [6]. In this study the cable solution has been implemented and tested. As already stated in chapter 3, the protocol between the car and the key is a challenge-response protocol, the signal between the car and the key is a short range low frequency (LF) signal while the signal from the key to the car is an Ultra High Frequency (UHF). The attack idea is to relay the car’s beacon far away, in order to trigger the key to answer. It’s not necessary to relay also the other direction (key to car), as the UHF signal can reach distances of 10-100 meters. Two LF have been built using rame cables as shown in figure 27. The two antennas are connected via cable. By placing an antenna inside the car and the other one near the key fob, a PKES car’s engine will start even if the legitimate user is out of the range of the car receiver. However, the cable that links the two antennas is the bottleneck, limiting the distance exploitable for the attack. In fact, the challenge-response protocol implemented in PKES car is time limited: if an answer from the key fob doesn’t reach the car within a certain amount of time, that can vary between the order of nanoseconds and milliseconds [6], the attack will fail. The cable introduces a delay (30-40% slower) in the wave propagation if compared with the propagation via air. Even if the attacker can hide a very long cable from the user, the attack will be still limited by the timeout constraint of the protocol.
44
10. Jam detector
To avoid an attack like jamming or a jam and reply, a jam detector is required. This application is specific for HackRf due to the fact that uses directly the HackRf library, ported to Java by Dennis Mantz [13]. The application uses HackRf as a receiver to detect if there is any signal at a certain frequency with a magnitude level above a threshold and that has lasted for some seconds. The application allows to select some parameters: sample rate, frequency, vga gain. There are 4 buttons: Open, Learn, Rx, Stop.
Open: establishes a connection with HackRf and set the queue to receive the packets from the sdr
Stop: interrupts the task that is being executed
Learn: the application starts monitoring the signals at the specified frequency for some time and set a threshold value based on the results found. The threshold is used to find jamming signals
Rx: starts monitoring for jamming
In details:
Open:
Packets are received in the app through a shared concurrent structure. A blocking queue mechanism is implemented, as in Figure 28, HackRf puts in the queue packets of 16KB and
Figure 28- Scheme of packets exchange between hackrf and the android application through a concurrent blocking queue
45
the app then polls them. Packets contain several I/Q sample, every sample has 8 bits for I part and 8 for Q part. When the button Open is clicked, the function openHackrf() in called and the blockingQueue is initialized.
Jam detection:
Figure 30- Initializing jammer detection Figure 29- Initialize hackrf
46
The application is multithreaded: one to handle user interaction with the interface, to poll the packets from the concurrent structure and determine if there is a jamming or not, one to handle any graphic change at runtime and one that handle the task “learning” or the task to compute the maximum amplitude value received. The code in Figure 29 shows the initialization of the jammer detection: if the flag “learning” is not set it means that we are going to receive packets the must be analysed, by measuring the amplitude, to discover the
presence of a jammer. To fulfil this task, amplitude Thread is started(). HackRf will put packets received into the arrayBlockingQueue.
Every 1000 packets received the maximum value found by the “ComputeMax” task is compared with the threshold established during the learning phase. If it is above, a counter is incremented. The value of the counter is then compared to another threshold Thc (in the code in figure 31 this is directly represented by the value 4), if above it, we are in the presence of a signal that has lasted for some seconds and that is above the noise threshold value. The max value found by “ComputeMax” is then stored into a variable. We remain in the presence of a jamming until a value that is below the threshold is found.
The application estimates the proximity from the source of jamming by storing the last max amplitude value and comparing it against the new one. If the difference between these ones
47
is more (or less) than 1.3, it means that we are moving closer (or further) to the jamming source. The value 1.3 has been set after many tests evaluating the precision of the detection.
Detection scheme: Learning task:
This is the task that is executed to find a threshold value. When the task is executed, the first 3000 packets received are discarded; this is because HackRf has a certain setting time when starts receiving, so some packets may contain NaN value or 0. After that, it samples the byte array every X pairs I/Q. The value X is a trade-off between accuracy and performance, with more powerful smartphone it could be very close to 1. The application was tested on an Asus Zenfone 2. During the test X was equal to 12.
Is above Threshold? && Counter=X? Check detected value for X
iteration
Jamming
Check detected value, is below threshold?
MaxAmplitude old – MaxAmplitude new No jamming
Getting further to source Getting nearer to source
Yes
No Yes
< 1.3 > 1.3
48
For every pair it then converts into float both the I and Q value and computes the amplitude value with the formula sqrt(I^2+Q^2).
At the end of the loop, the array containing the amplitudes values is sorted and the mean value of the 100 biggest value is computed. The threshold is then set to 1.4 times the mean value found. Both 100 and 1.3 were set after many tests, considering the accuracy of the detection at different values.
Computing max task:
This task computes the max amplitude value found every 1000 packets received and sets the appropriate shared variable with this value.
49
11. Conclusions
The tests have proved the possibility to perform a jam&replay attack even with a low-cost configuration. Of course, with a more precise SDR, like USRP for example, the distance exploitable will be even further. However even with just an HackRf (~ 300€) and a rtl-sdr (<15€) the attack is possible. Different SDRs have different precision due to different hardware, this can be observed in the frequencies reported in the table for the same car models but in different configurations. Another difference is the receiver’s range of accepted frequencies: some models, like model 3 has a very wide bandwidth (~1Mhz) while cars, like model 4, have a shorter one (~ 50 Khz).
Relay attack via cable has proven the possibility for an attacker to open and start a PKES car. This attack can be combined with the jam & replay in cases in which the vehicle has a passive start but not a passive opening system. The limits are the maximum distance exploitable and the difficulty in hiding the cable from the victim’s view.
50
References
1. Lock It and Still Lose It—On the (In)Security of Automotive Remote Keyless Entry Systems'-Flavio D. Garcia and David Oswald, University of Birmingham; Timo Kasper,Kasper & Oswald GmbH; Pierre Pavlidès, University of Birmingham In Proceedings of the25th USENIX Security Symposium August 10–12, 2016 Austin, TX 2. 'Broken keys to the kingdom Security and privacy aspects of RFID-based car keys'- Jos
Wetzels on arXiv
3. 'THE CAR HACKER’S HANDBOOK A Guide for the Penetration Tester' - Craig Smith 4. DEF CON 23 - Samy Kamkar - Drive it like you Hacked it: New Attacks and Tools to
Wireless (https://www.youtube.com/watch?v=UNgvShN4USU)
5. Atmel AVR411: Secure Rolling Code Algorithm for Wireless Link- application note 6. ‘Relay Attacks on Passive Keyless Entry and Start Systems in Modern Cars’ ,Francillon,
Aurélien; Danev, Boris; Capkun, Srdjan, IN PROCEEDINGS OF THE 18TH ANNUAL NETWORK AND DISTRIBUTED SYSTEM SECURITY SYMPOSIUM. THE INTERNET SOCIETY 7. Security Analysis of a Cryptographically-Enabled RFID Device'-Stephen C. Bono
Matthew Green Adam Stubblefield Ari Juels Aviel D. Rubin Michael Szydlo In SSYM'05 Proceedings of the 14th conference on USENIX Security Symposium - Volume 14 8. Security Analysis of an Open Car Immobilizer Protocol Stack' - Stefan Tillich and Marcin
Wojcik University of Bristol, Computer Science Department UK In book: Trusted Systems, pp.83-94
9. TRAINING MANUAL Immobilizer System- Mazda
10. Tecnologia RFID, Introduzione e rassegna delle tecnologie di identificazione a radiofrequenza - Paolo Talone –Giuseppe Russo
11. ‘Experimental security analysis of a modern automobile’ K. Koscher, A. Czeskis, F. Roesner, S. Patel, T. Kohno,S. Checkoway, D. McCoy, B. Kantor, D. Anderson,H. Shacham, and S. Savage on IEEE Symposium on Security and Privacy. IEEE Computer Society, May 2010.
12. ‘Turn-Key Passive Entry/Passive Start Solution: the Atmel PEPS’-Jedidi Kamouaa 13. Dennis Martz hackrf library for android:https://github.com/demantz/hackrf_android
