DEGREE PROJECT IN MECHANICAL ENGINEERING, FIRST CYCLE, 15 CREDITS STOCKHOLM, SWEDEN 2020

Relay Attack Resistant Passive Keyless Entry Securing PKE Systems with Immobility Detection

ABEL VALKO

KTH ROYAL INSTITUTE OF TECHNOLOGY SCHOOL OF INDUSTRIAL ENGINEERING AND MANAGEMENT

Relay Attack Resistant Passive Keyless Entry

ABEL VALKO

Bachelor’s Thesis at ITM Supervisor and Examiner: Nihad Subasic

TRITA-ITM-EX 2020:48

Abstract

A significant security risk of modern vehicles is their vulner- ability to relay attacks, due to challenge-response methods, such as those employed in Passive Keyless Entry (PKE) used by most commercial cars, being inherently exposed. This class of attacks are where communication between a vehicle and its key is relayed by an attacker over long range - thereby bypassing any encryption and unlocking the ve- hicle without requiring direct access to the key. While a multitude of defenses have been proposed in recent years, many lack either robustness or practicality. Any viable sys- tem will likely have to rely on an environmental parameter which is not easily manipulated. Moreover, the system has to be: cost effective; easily implementable; and take user comfort, such as the key’s battery life, into account. This thesis implements and evaluates a PKE system re- sistant to relay attacks, analyses a multitude of proposed strategies in literature for feasibility, as well as suggests a novel method: Approach Curve Matching. It is concluded that the most promising strategies are: Immobility Detec- tion, Distance Bounding Protocols, and Approach Curve Matching - the first of which is chosen to be implemented in the prototype PKE system. The project develops a PKE system and implements the communication protocol using Bluetooth, as opposed to the conventional RFID. Immobility Detection, using an ac- celerometer, is then implemented. The final system is then tested and evaluated. It is concluded that while Immobil- ity Detection is not comprehensively effective, it is easily implementable, cost-effective, and can greatly increase the security of PKE systems. Finally, it is proposed that Immo- bility Detection should be employed promptly by manufac- turers while investigating potentially more effective, albeit uncertain, strategies.

Keywords: Passive Keyless Entry, Relay Attack, Mafia Fraud, Access Control, Mechatronics Referat

En betydande s¨akerhetsbrist av moderna fordon ¨ar deras s˚arbarhetmot s˚akallade ’relay attacker’. Dessa typer av attacker, d¨ar signaler mellan bilen och nyckeln vidarebe- fordras, kringg˚arall kryptering och l˚aserupp bilen utan att ha direkt tillg˚angtill nyckeln. En stor del av kommersiella fordon till¨ampar ’Passive Keyless Entry’ (PKE) som byg- ger p˚a’challenge-response’ metoder som visats vara s¨arkilt utsatta f¨or dessa attacker. En m¨angd olika skyddssystem har f¨oreslagits p˚ase- nare ˚ar,men m˚angasaknar erforderlig robusthet eller ge- nom¨orbarhet. Ett l¨ampligt system b¨or uppfylla en rad olika kriterier. Strategin m˚astegrundas p˚aen omgivningspara- meter som ¨ar b˚adeof¨or¨anderlig och tillr¨ackligt rymdbero- ende att tv˚an¨ara positoner kan skiljas ˚at.Dessutom ska systemet vara kostnadseffektivt, implementerbart, och ta h¨ansyn till anv¨andarkomfort s˚asombatteritid. Projektets huvudsyfte ¨ar konstruktionen och analysen av ett ’relay attack’ resistent PKE system. I detta projekt ing˚arocks˚aen analys av ett antal f¨oreslagna f¨orsvar och ett f¨orslag om en ny metod: ’Approach Curve Matching’. Slut- satsen dras att de mest lovande taktikerna ¨ar: analys av Jac- card indexet av Wi-Fi hotspots, ’Distance Bounding Pro- tocols’, ’Approach Curve Matching’ och ’Immobility Detec- tion’ som ocks˚aimplementeras i prototyp PKE systemet. Projektet utvecklar f¨orst ett PKE system med tv˚aRasp- berry Pis som agerar som bilens och nyckelns mikrodatorer och implementerar kommunikationsprotokollet med hj¨alp av Bluetooth. ’Immobility Detection’ ¨ar sedan implemen- terad genom en inbyggd accelerometer i nyckeln. Slutligen testas och utv¨arderas systemet. Det konkluderas att trots att ’Immobility Detection’s effektivitet inte ¨ar helt omfat- tande ¨ar den l¨att att implementera, kostnadseffektiv, och kan bidra till en betydlig ¨okning av s¨akerheten hos PKE system. Vidare observerade projektet att Bluetooths ’Re- ceived Signal Strength Indicator’ (RSSI) m¨atningar ¨ar ut- satta f¨or avsev¨ard ostadighet och ¨ar allm¨ant omgivningsbe- roende. D¨arf¨or anses Bluetooth RSSI inte l¨amplig f¨or PKE till¨ampningar ¨aven om andra metoder f¨or avst˚ansm¨atning med Bluetooth kan ha h¨ogre prestanda. Det f¨oresl˚asatt ’Immobility Detection’ till¨ampas av tillverkare omg˚aende medans andra potentiellt mer effektiva strategier utreds.

Keywords: Nyckell¨osa System, Atkomstkontroll,˚ Relay Attack, IT-s¨akerhet, Mekatronik Acknowledgements

Thanks are owed to the team of course assistants who have helped during the course of this project and my peers for their opposition and discussion on the thesis. I would also like to extend my gratitude to Andras Valko, Balazs Valko, and Janos Valko for fruitful discussions and brainstorming, and for providing invaluable support throughout the thesis.

Abel Valko May 2020 Contents

1 Introduction 1 1.1 Purpose ...... 2 1.2 Scope ...... 2 1.3 Method ...... 3

2 Background 5 2.1 Passive Keyless Entry ...... 5 2.1.1 Overview ...... 5 2.1.2 Encryption ...... 7 2.2 Relay Attack ...... 8 2.2.1 Overview ...... 8 2.2.2 Limitations ...... 9 2.2.3 Threat ...... 10 2.3 Key Fob Design ...... 10 2.3.1 Battery ...... 10 2.3.2 Wireless Technology ...... 10

3 Proposed Defenses 13 3.1 Received Signal Strength Indicator ...... 13 3.2 Coordinate Tracing ...... 13 3.3 GPS ...... 14 3.4 Jaccard Similarity of Wi-Fi Access Points ...... 15 3.5 Distance Bounding ...... 16 3.6 Immobility Detection ...... 17 3.7 Approach Curve Matching ...... 17

4 Implementation 21 4.1 Hardware ...... 21 4.1.1 Microcomputer ...... 21 4.1.2 Bluetooth Module ...... 21 4.1.3 Accelerometer ...... 22 4.1.4 Locking and Servo Motor ...... 22 4.2 Software ...... 23 4.2.1 Logic ...... 24 4.2.2 Authentication Protocol ...... 24 4.2.3 Software Architecture ...... 25 4.2.4 Encryption ...... 26 4.3 Results ...... 26

5 Discussion 29

6 Conclusion 31

Bibliography 33

Appendices 37 A ZOE-M8B GPS Module Data-sheet (excerpt) ...... 37 B Power Consumption Measurements for WF(M)200 Wi-Fi Module (excerpt) ...... 45 C AIS2DW12 Accelerometer Data-sheet (excerpt) ...... 50 D CAD Model of Demonstrative Locking Mechanism ...... 53 E Python Code for the Designed PKE System - Key ...... 55 F Python Code for the Designed PKE System - Vehicle ...... 68 G Test Cases ...... 77 List of Figures

2.1 Protocol diagram of typical PKE system...... 6 2.2 Inner and outer RFID zones...... 7 2.3 Agent entering between the car and key fob communication...... 8 2.4 Protocol diagram of relay attack on PKE System...... 9 2.5 RFID beacons placed around the car interior and exterior...... 11

4.1 Connection diagram for the MPU6050 accelerometer to Raspberry Pi Zero. 22 4.2 Activity diagram of the unlocking process for the improved PKE system with Immobility Detection...... 23 4.3 Sequence diagram of a successful unlocking sequence...... 25 4.4 Prototype setup of the implemented PKE system with the key fob and accelerometer (left) and on-board computer and lock (right)...... 26 List of Abbreviations

BLE Bluetooth Low Energy

DTW Dynamic Time Warping

GPIO General Purpose Input/Output GPS Global Positioning System

LF Low Frequency

PKE Passive Keyless Entry PKES Passive Keyless Entry and Start PWM Pulse Width Modulation

RF Radio Frequency RFID Radio-Frequency Identification RKS Remote Keyless System RSSI Received Signal Strength Indicator

SARA Signal Amplification Relay Attack SMBus System Management Bus

UHF Ultra High Frequency

Chapter 1

Introduction

In Sweden alone there are near five million registered, in use, personal vehicles [1]. Approximately one vehicle for every two individuals [2]. The rapidly increasing connectivity of these vehicles and the shift from mechanical to electronic and wireless systems gives rise to new security vulnerabilities. Modern methods of car theft are a prime example of newly digitalized exploits owing to the spread of digital lock systems. The Remote Keyless System (RKS) has all but replaced the previous mechanical lock mechanism in cars with its Passive Keyless Entry (PKE) variant becoming standard in most high-end brands instead of its active counterpart. The traditional active RKS is a unidirectional system where the user unlocks the vehicle with a remote control, a.k.a. ’key fob’. The PKE System, explained in detail in Section 2.1, unlocks the car automatically as the user approaches the vehicle with the key fob - without the need for any interaction with the user interface. It employs bidirectional communication where the car sends a wake-up signal to the key when it is within range (commonly under 1 meter) and the driver takes hold of the handle, proceeded by a challenge response from the key which, if correct, will unlock the vehicle. A similar check may be performed in order to start the vehicle [3, 4]. This system increases user comfort due to the eliminated interaction and with the encryption algorithm and challenge-response technique that is employed in most recent implementations, explained in Section 2.1, assures high resistance to many methods of attacks. However, it is not secure against relay attacks - also known as Mafia Fraud - and Signal Amplification Relay Attack (SARA) which are attacks that do not require decryption and are not affected by the encryption algorithm’s complexity, nor can they be eliminated using alternative protocols [4, 5]. A review by G¨ulsever of Upstream’s, a cyber security company’s, repository consisting of security incidents relating to the automotive industry show 187 exploits related to connected cars with 25 unique attack vectors (paths that allow an attacker to gain access to a system) identified [6]. RKS vulnerabilities accounted for the largest number of them as well as having the largest ratio of ’black hat’ (malicious as opposed to ’white hat’ - research) attacks. Various suggested security features exist that could protect a PKE System from relay attacks. These include context based

1 CHAPTER 1. INTRODUCTION systems using relative position of car and key fob, comparison of Wi-Fi access point lists, Global Positioning System (GPS) coordinates etc [3, 4, 7, 8]. This thesis analyses these proposed defences as well as suggests a novel way of protection, constructs a prototype system with the chosen method - Immobility Detection - and evaluates said system.

1.1 Purpose

This project, within the scope of a Bachelor’s Thesis in Mechatronics at KTH Royal Institute of Technology, aims to construct a prototype PKE System as a proof of concept for relay attack resistance by way of Immobility Detection. It aims to analyze and evaluate the effectiveness and feasibility of an added ’sleep-mode’ to existing PKE Systems in relation to existing and other proposed security features. This is summarised in the following research questions:

• How effective is Immobility Detection as a method of protection against relay attacks and how feasible is its implementation in PKE systems?

• How does Immobility Detection compare to other potential methods of protec- tion against relay attacks? Can it be supported by other methods for increased protection?

• Is Bluetooth Low Energy (BLE) a viable alternative to Radio-Frequency Iden- tification (RFID) in PKE systems?

1.2 Scope

This paper aims to present a proof of concept implementation of relay attack resis- tance using an accelerometer in a PKE System’s key fob. As such it is constrained to the implementation of the base functionality of a PKE System. However, it does not include some of the more robust features deemed irrelevant for this thesis. The implementation of encryption used in modern systems, such as KeeLoq [8], optimi- sation of power consumption, as well as physical robustness are considered outside the scope of this study. It is assumed for the purposes of this thesis that the encryp- tion protocol is reliable and has the required complexity to be undecipherable, thus no consideration is given to it. A simple mechanical system is also demonstrated which serves merely as a visual representation of the door lock. Power consump- tion, especially of the key fob, is an important aspect to consider with any proposed solution. This project considers the effects of added features and sensors on battery life but does not take this into consideration in the physical prototype. Based on the project’s needs as well as economic and time constraints the hardware chosen is as presented in Chapter 4.1. Additionally, this paper presents several alternative methods of protection found in the literature. These are summarized and briefly evaluated for effectiveness and

2 1.3. METHOD feasibility and subsequently compared to the solution presented and developed in this thesis.

1.3 Method

This study has been conducted in the following six phases; initial problem formu- lation, preliminary solution brainstorming, research, problem and solution speci- fication, construction and, finally, evaluation. Once the problem was identified, various possible solutions were brainstormed and evaluated. Several of these were later found to be methods suggested by other papers or supported by the industry. In the subsequent research phase all methods were rigorously assessed. The sug- gested solution was then concretized. A Raspberry Pi Zero W was chosen as the microcomputer for its price, simplicity, as well as wireless capabilities. The commu- nication protocol was implemented using Bluetooth as opposed to the conventional RFID. The setup was constructed with all necessary dimensions for functioning as a suitable demonstration of the concept, omitting certain irrelevant features. The implemented solution was then evaluated and compared to other proposed solutions.

3

Chapter 2

Background

The following chapter outlines all the required information for complete analyses of the proposed defenses. Understanding current PKE implementation - into which any defense must be integrated - both in terms of limitations and potential is crucial for assessing viability of any system. In order to judge the effectiveness of proposed strategies the chapter also presents a high level overview of relay attacks.

2.1 Passive Keyless Entry

2.1.1 Overview

The PKE system, replacing the active remote keyless entry system that preceded it, was first introduced in 1998 by Mercedes Benz and is considered to increase comfort of use as it negates the need for a key press when unlocking the vehicle [9]. Instead, PKE systems allow users to unlock the doors by approaching the vehicle and grabbing the door handle with the key fob on their person. There are variations in protocol and exact implementation, discussed in Section 2.1, but the following steps demonstrate a typical version [8]:

1. The car periodically broadcasts a wake-up message on a Low Frequency (LF) RFID channel, approximately around 130 kHz, probing for nearby keys [3, 8].

2. As the key fob approaches the vehicle and enters the LF RFID’s effective range it receives the wake-up message and is powered on by inductive coupling from the car’s signal. It will respond with an acknowledgement on an Ultra High Frequency (UHF) RFID, around 315MHz (this is done in order to save power).

3. The car proceeds to send a challenge (essentially a request for the password) via LF RFID including an identifier to the car.

4. The key receives the challenge and, if the identifier matches the key’s, responds with the challenge response.

5 CHAPTER 2. BACKGROUND

5. The car then unlocks - assuming that the challenge response is accepted.

While variations on this system exist, such as omitting the wake-up or requiring double verification, the core functionality is the same across manufacturers [3, 8].

Figure 2.1: Protocol diagram of typical PKE system. (Figure made with draw.io)

The same process as described above is presented in Figure 2.1. A variation on this system is the Passive Keyless Entry and Start (PKES) system which has an additional sequence similar to the one detailed in Figure 2.1 when the user enters the vehicle, allowing engine start with the push of a button on the dashboard.

6 2.1. PASSIVE KEYLESS ENTRY

Figure 2.2: Inner and outer RFID zones. [8]

For this, two RFID zones are required, as depicted in Figure 2.2, with one reaching outside of the car (generally in a range no more then one meter from the doors) for unlocking and one exclusively on the inside of the vehicle for starting the engine. Note that while the LF zones are strictly in a few meter radius around the car the range of the UHF transmitter can be significantly larger [3, 4, 7, 8].

2.1.2 Encryption While this paper does not focus on the encryption algorithms used in PKE systems it is briefly summarized as follows: Both the vehicle and the key fob share a secret hardware key unique to a manufactured vehicle. When the key fob has acknowledged that it is in range the car generates a pseudo-random code to be transmitted as the challenge. The key receives the challenge and uses it to generate a response using a cipher such as KeeLoq or DST [8]. During this time the car will also generate the response and compare it to the received response from the key. In theory, this is a one-way operation which can neither be predicted, reverse engineered, or brute- forced. While the cryptography method used in PKE can itself be attacked [10], this goes beyond the scope of this paper; which assumes that the encryption method can be fully relied upon.

7 CHAPTER 2. BACKGROUND

2.2 Relay Attack

2.2.1 Overview

Relay attacks, also known as Mafia Fraud, have multiple forms, though all rely on the same fundamental principles. It is a man-in-the-middle attack, a method by which an agent (in this case a relay) steps between two (or more) devices and forwards (a.k.a. relays) signals between them, see Figure 2.3. This allows the agent to essentially pose as a trusted device without having to know any details of the secure communication. This type of attack is commonly employed with parked cars with the key in a relatively close range, such as inside a house or in the pocket of the driver at a store, cafe, or similar [3].

Figure 2.3: Agent entering between the car and key fob communication. (Figure made with draw.io)

As mentioned previously, while the LF RFID needed to establish connection between the key and car has a range limited to approximately a meter from the vehicle, the range of the UHF response sent by the key can have a much greater range: analogous to actively unlocking the car with the button. This leads to certain systems being vulnerable to amplification attacks where a signal, in this case the challenge from the car, is amplified to the key. Since the car broadcasts the challenge periodically, without prior verification that the key is in range, this can be picked up by a relay device and amplified. The key receives the signal, verifies that it has the correct ID associated with the key, and responds to the challenge accordingly. If the car and key are within range of the UHF signal, such as in the driveway and inside a house, the car is immediately unlocked. (An extra wake-up verification cycle may also be executed.)

8 2.2. RELAY ATTACK

Figure 2.4: Protocol diagram of relay attack on PKE System. (Figure made with draw.io)

In cases where the range of the UHF RFID is not sufficient, or where a vehicle with PKES is to be started and driven away, two agents are commonly needed. This is analogous to a SARA but relays bidirectionally. Figure 2.4 illustrates a modified version of Figure 2.1 illustrating this attack. Note that the effectiveness of relay attacks are not diminished by increased cryptographic complexity as no cracking of the cipher is needed.

2.2.2 Limitations While relay attacks are very effective against current PKES Systems they do possess inherent limitations which can be exploited when attempting to safeguard against it. While relay attacks benefit from not having to interpret the signal or having to crack the underlying encryption this also means that information can be sent safely, which is crucial to several context-based protection mechanisms as discussed in Chapter 3. Relay attacks also add delay to the sequence, exploited in for example distance bounding methods. In addition, the relay devices require to be within range of both the door and the key. Lastly, while the attacker can trick the car into

9 CHAPTER 2. BACKGROUND believing that it is the key, the key fob itself can not actually be manipulated. Its position, environmental characteristics, sent message, etc. are not affected by the attack; a fact that can be utilized to design an effective defence.

2.2.3 Threat

Given the above, what threat do relay attacks actually pose? While conclusive statistics on the occurrence of relay attacks are very difficult to find, these at- tacks have been demonstrated in countless studies, reported on in news outlets, and caught on security footage [11, 12]. While specific implementations vary even within a single manufacturer’s different car models, decreasing the effectiveness of a single setup, it has been found that vulnerability in modern vehicles is widespread with many, if not all, vehicles with PKE being susceptible [8]. Furthermore, while hard- ware availability and price was previously a mitigating factor, a Chinese security research team succeeded in demonstrating a relay attack on a PKE System from a maximum of 320 meters using 20 Euro equipment in 2017 [3, 13].

2.3 Key Fob Design

2.3.1 Battery

When suggesting potential defenses against relay attacks it is crucial to put these into the context of existing systems and technical limitations. Battery limitations of the key fob are often ignored in otherwise rigorous studies, such as the paper published by J.Wang et al. which suggests a combination of various defenses despite their unfeasability in real-world applications, see Chapter 3 [7]. The main advantage of PKES systems over previous ones is comfort and simplicity which is negated if constant battery replacement becomes an issue. While it is outside the scope of this paper to provide a detailed analysis of power consumption of key fobs it is necessary to have a basic estimate in order to verify the feasibility of the suggested defences. The 2018 Lexus NX300h is taken as an average vehicle with PKES; it uses a CR2032 button cell battery of 3 V and a capacity of 220 mAh [14]. According to the vehicle’s user manual the batteries are generally expected to last one to two years [15]. As a very rough estimate for general comparisons it can be said to have a consumption of 220/(365 ∗ 1.5) = 0.4 mAh per day. This estimate can be used for evaluating the added power consumption of proposed solutions.

2.3.2 Wireless Technology

While specific frequencies differ due to regulations, the technology used for commu- nication between the key fob and the on-board computer in the vehicle is generally the same for all manufacturers. An LF channel is used for wake-up while authenti- cation is processed using a UHF channel. The nature of this technology allows for

10 2.3. KEY FOB DESIGN low power usage while idle, inductive coupling for wake-up, as well as a generally simple but robust interface. A separate set of RFID transceivers may be present inside and outside of the car so that it can be determined if the key fob is within or without the vehicle, as seen in Figure 2.5. An alternative may be to simply create different zones in and around the car which can easily be distinguished between.

Figure 2.5: RFID beacons placed around the car interior and exterior. [16]

While most current manufacturers use RFID technology for their PKES systems, BLE is an emerging technology for secure access control and indoor positioning solutions. Unfortunately, distance measurements using Received Signal Strength Indicator (RSSI) or Rx power (received signal power, measured in dBm) have been consistently shown to be inaccurate. Mesh networks and trilateration techniques may increase accuracy, but these are not viable solutions for PKE systems. One study in a static indoor environment showed that due to the multipath interference caused by metallic surfaces distance measurements using BLE RSSI resulted in a mean absolute position error of approximately 1.2 m [17]. While this may be sufficiently accurate for some applications it is not viable for a premium consumer product which is expected to be substantially more consistent. However, in late 2018 Imec demonstrated a system using BLE that has excellent accuracy of distance measurement and claims to be immune to sophisticated dis- tance manipulation that other defense measures are still susceptible to [18]. With its low power consumption and potential for high accuracy BLE could come to re- place RFID based PKES systems. Furthermore, it can enable novel access control systems such as those needed for unlocking carpooling vehicles with mobile phones, or other access sharing applications.

11

Chapter 3

Proposed Defenses

The following defenses are potential solutions to the vulnerabilities of PKES sys- tems as proposed by this study and supported by previous research. Many effective defenses employ context-based verification where there is an independent verifica- tion of an environmental parameter by the key fob and vehicle followed by a mutual authentication. If this parameter is chosen right it is sufficiently complex and space variant that there exists a clear difference in its value near the car and some me- ters away. Ideally, the environmental parameter is also resistant to manipulation, or spoofing. While many of the following approaches are effective methods of pro- tection on paper, the implementation of these are often not considered by other studies. After the analyses below, prototyping, and evaluation, this paper discusses the ideal defense strategies in Chapter 5.

3.1 Received Signal Strength Indicator

Received Signal Strength Indicator (RSSI) is a measure of the approximate power level of a received signal. There exist suggestions to use this to verify proximity to the car [19], however, this is essentially already what is implemented by the LF RFID wake-up. The key only replies when it detects a signal with enough power. This is however easily duped using a relay attack or signal amplification relay attack.

3.2 Coordinate Tracing

This is a method proposed amongst others by S. Rizvi et al. where either the LF signal’s RSSI or a different communication channel such as Bluetooth is used to triangulate the position of the key and compare it to that of the vehicle’s [4]. There are a multitude of difficulties with this. The first problem arises already with the implementation on the vehicle side. S Rizvi et al. proposes using the GPS already included in most cars’ entertainment systems. This, if possible at all due to regulations, would require a large overhaul

13 CHAPTER 3. PROPOSED DEFENSES of how access is managed to the vehicle’s features while locked. A highly costly and unpractical operation. A further issue is that of accuracy. RSSI can be used for relative positioning but due to its inaccuracy and susceptibility to physical interference it is not suitable for exact positional measurements. Even assuming that the accuracy is sufficient, the solving of simultaneous equations needed for triangulation are extremely demanding and would require a more expensive chip in the key fob and cause greatly increased power consumption. This method, while theoretically sound, is practically impossible to implement. It is far too complex, computationally intensive, and even inaccurate.

3.3 GPS

One suggested defense against relay attacks is location verification using GPS [7]. This proposes using the often already included GPS in the vehicle’s on-board com- puter as well as an added GPS in the key fob for independent location measure- ments. The measured coordinates of the key can then be transmitted together with the wake-up acknowledgement or challenge response and compared by the vehicle with its known position. This would in theory allow verification of the distance between the devices. This solution however has several major flaws. Firstly, the accuracy of GPS measurements may not be suitable precisely for this type of close range applica- tion. GPS is intended to provide specific location measurement with a guaranteed accuracy in the United States of under 7.8 meters with 95% certainty [20]. While the reported accuracy is greater than this, hardware quality, interference, weather conditions, and other factors can greatly influence the effective accuracy. This is far from accurate enough for definitive protection against relay attacks where distances of a few meters can be crucial. GPS can furthermore be susceptible to spoofing attacks [7]. A further problem with implementing a context-based verification grounded on GPS technology is the power consumption of the GPS module and accompanying calculations. As an example, the ZOE-M8B [21], see Appendix A, released in 2019, marketed as a compact low power chip, has a typical power requirement of tens of mAs while active. A consumption far from negligible. Furthermore, it has a long ”Time-To-First-Fix” (the time taken to calculate a position after startup) with around 30 seconds ”cold-start” (without previously saved GPS data, used unless previous position is similar). Moreover, this module is rather expensive, costing above 10 Euros. While it claims to possess spoofing detection, a feature enabling it to detect if the GPS signal is manipulated externally such as an attacker might do to bypass the verification system, it does warn that this may not detect all spoofing attempts. Furthermore, the accuracy of this specific module is likely not sufficient, claiming accuracy to around 3 meters. [21] Other manufacturers may have more accurate or faster GPS modules, though

14 3.4. JACCARD SIMILARITY OF WI-FI ACCESS POINTS it is likely that they would have even greater power consumption and cost, making them unviable for this application. While verification with GPS may become viable in the future with more efficient, accurate, and cheaper components it can be con- cluded from the above analysis that it is as of now not a solution suited for PKES Systems.

3.4 Jaccard Similarity of Wi-Fi Access Points

One potential countermeasure against relay attacks, also proposed by researchers at Queen’s University, Kingston, Ontario, is using the Jaccard index of Wi-Fi access points detected by the key and car to ensure spatial proximity [7]. This is the intersect of the available Wi-Fi access points for the two devices divided by the union of these and measures the similarity of the Wi-Fi access point lists. An inbuilt Wi-Fi module in the key would scan for hotspots and return the list with eventual accompanying data, such as RSSI, to the vehicle for verification, which would compare it to its own list. The vehicle would only be unlocked if the Jaccard index is sufficiently high. There are several challenges with this method worth discussing. Firstly, a po- tential issue could be increased battery usage. The power consumption associated with the added feature is roughly analyzed below. The Silicon Labs WF200 series transceiver module is targeted specifically at low-power IoT applications and should suffice as a reference [22]. With the assumptions in Chapter 2.3.1 and further as- suming an average of 2.5 trips (and therefore authentications) per day as presented by the European Commission’s 2012 survey on driving patterns [23] the following calculation can be made: With a Wi-Fi scanning duration of 951.26 ms at an av- erage of 51.76 mA, see Appendix B, the scanning alone adds up to a consumption of 0.034 mAh per day contributing to a power increase of 8.5%. Note that this disregards any additional battery usage due to lengthier messages, extra computa- tion, or the need for a more advanced microprocessor. While not prohibitive, this increase in power consumption is not insignificant. Further issues include inherent characteristics of Wi-Fi hotspots and their scan- ning. For example, with a scanning time of around one second, the WF200 transceiver is not fast enough to be used for authentication upon unlocking. The authentication takes place in the time between the user placing her hand on the door handle and pulling it, and so any security feature that is added must be significantly faster. However, the Wi-Fi authentication could be processed after unlocking but before ignition. This would not protect against theft from vehicles, but it would protect against the much more costly theft of the vehicle itself. The actual implementation of such a system would also have to be rigorously tested for various conditions. Potential issues may be empty hotspot lists, not enough distinction between lists for close (but out of range) devices, or hotspot lists over-saturated with low RSSI signals. These would all have to be tested and calibrated for before the method can be deemed conclusively effective.

15 CHAPTER 3. PROPOSED DEFENSES

The main appeal of using Wi-Fi hotspots for relative localisation is also a large drawback, namely the universality of the technology. While Wi-Fi hotspots exist almost everywhere in populated areas, it is also a technology that can be cheaply and easily spoofed. An attacker could, with readily available equipment, merely create a few high strength hotspots beside both the key and vehicle thereby drowning out ’real’ hotspots. Such tampering could potentially be detected and defended against, for example by filtering suddenly appearing hotspots or hotspots with suspicious RSSI fluctuations. This, however, adds a great level of complexity to the solution, increasing power consumption, lowering effectivity and time efficiency, as well as greatly increasing development costs and time.

3.5 Distance Bounding

A potential solution to access control, not only in PKE systems but for any wireless or wired application relying on an untrusted prover needing to prove proximity, is distance bounding. This is a method of determining an upper limit to the physical distance a prover, in this case the key or attacker pretending to be the key, can be from the verifier: the car. This is done by measuring the time for signal propagation from verifier to prover and back. If Radio Frequency (RF) is used then, due to nothing being able to communicate faster than the speed of light, the protocol can establish a physical upper bound for the distance between the devices with the only uncertainty arising from the processing speed of the prover. For every 1 ns delay due to processing, the window for the attacker - assuming they can act in zero-time - increases by 15 cm. This means that both the hardware, the protocol and the underlying function which is needed to guarantee the identity of the prover need to be highly optimised. The function applied to the challenge has a similar purpose as any encryption used for challenge response in current systems but must be significantly faster. Even a simple XOR adds time delays that render the protocol unusable. The first distance bounding protocol for RFID was introduced in 2005 by Hancke and Kuhn [24] with the first demonstration of a protocol with the required security features - to some degree at least - was done in 2010 by Rasmussen and Capkunˇ [25]. Their implementation achieved processing in approximately 1 ns, resulting in an accuracy only 15 cm outside of the theoretical maximum. While the protocol has been shown to be susceptible to certain types of attacks [26, 27] there have been improved versions proposed [28]. One such proposal and implementation by Hussein et al. is optimized for UHF RFID tokens and has greater security while maintaining a processing speed of 1 ns [29]. While distance bounding protocols are improving rapidly they are not yet ready to be implemented commercially. The implementations so far have been highly experimental in nature. Furthermore, the effective frequency channels of such pro- tocols are limited. Rasmussen and Capkunsˇ set up for example was effective around 3.5 GHz but admitted to not being functional at lower frequencies [30]. We can con-

16 3.6. IMMOBILITY DETECTION clude that distance bounding as a protection against relay attacks has substantial potential in both PKE systems and other applications such as smart card readers but may not be a viable solution in the near future.

3.6 Immobility Detection

The situation where the vehicle is parked in the driveway with the key left near the door for the night is an ideal and, as presented in Section 2.2.3, common scenario for attacks. Immobility Detection, implemented and evaluated in Chapter 4, uses an accelerometer built into the key fob to detect when the key has remained motionless for a given amount of time and enter a ”sleep-mode” protecting from relay attacks. This method of protection is in the process of implementation by car manufacturers [31, 32]. While this does not protect against all instances of relay attacks, such as when the key is in motion, it has several advantages over many alternative proposals. It is simplistic and conclusive. Implementation is trivial, and does not involve much calibration or need for extensive data gathering such as, for example, location-based solutions. It is also clearly and unambiguously defined in its effectiveness. While it does not provide complete protection, the cases it does protect from can easily be outlined. Furthermore it is not an invasive alteration into the core functionality of the PKES System, with little to no modification needed, making it cost effective. While the choice of concrete component for commercial implementation is ir- relevant for this thesis, we can consider the AIS2DW12 accelerometer from STMi- croelectronics as an example [33]. A summary of the data-sheet can be found in Appendix C. The implementation presented in Chapter 4 uses a more common and easily implemented component, but is otherwise analogous. The above men- tioned accelerometer is, as claimed by the manufacturer, designed specifically for the automotive industry being highly resistant to all forms of abuse. With a cur- rent consumption in ”power-down” mode of maximum 950 nA, and allowing for the powering down of other components when in ”sleep-mode”, there is no negative, and perhaps a somewhat positive, effect on battery life.

3.7 Approach Curve Matching

A potential defense that, as far as this project could determine, has not been sug- gested by other researchers is what this thesis entitles Approach Curve Matching. This novel method is a protection mechanism where the measured approach curves from the key are compared to that measured by the car to establish validity of the access request. There are a variety of possible implementations, but they all follow the same basic logic. The key and vehicle individually record the signal strength of each other as the user approaches the vehicle. This results in two discrete data sets with signal strength, indirectly measuring distance, as a function of time which can then be compared. Assuming the data sets compared are trusted, ie., accurate and

17 CHAPTER 3. PROPOSED DEFENSES not fabricated by an attacker, we can clearly distinguish if the key approached the vehicle or not. A significant advantage of this method over Immobility Detection is being able to protect against relay attacks while the key is in motion, such as thefts in malls, outside stores, or in restaurants. In order for an attacker to bypass such a defence, they would need to ensure that the RSSI received by the key varies similarly in time as of that received by the car - a task potentially impossible owing to the strong effect environmental factors have on RSSI. This method can have multiple variations. The signal strength data could be one-dimensional, measuring only the distance to a single receiver in the vehicle, or multidimensional. However, measuring signal strength while entering the vehicle may not provide a distinct enough fingerprint, or enough time for measurement. In this case it is possible to employ this defense only for keyless engine start, by allowing the data collection to proceed until the user enters the car. The characteristic signal pattern of a key approaching the car, opening the door, entering the vehicle, etc., especially if multiple receivers are present in the car, would likely be complex enough to thwart any relay attack. Any attempt to oversaturate the signal by an attacker could also be detected, for example by comparing the approach curve to expected user motion. Moreover, a machine learning algorithm could be trained to identify approach curves that do not match common user patterns. Due to exact sampling time disparity and variations in the absolute value of the signal strength, Dynamic Time Warping (DTW) may be a suitable method for curve matching. However, due to the processor intensive nature of such an algorithm the data set from the key would likely need to be transferred to the vehicle’s on-board computer for analysis. This also implies that - since the authenticity of the data set must be ensured - the data set must be transmitted encrypted. While the encryption and extra transmission has an effect on the battery life, the intensive computations are on the vehicle side where more processing and battery power is available. By using no new components (only the existing wireless chip is used) the overhead power usage is not increased. The large number of extra transmissions needed to guarantee a robust dataset to base the curve matching on does draw battery power, but even older and somewhat outdated Bluetooth [34] and RSSI [35] chips rate their Tx currents around 10 mA resulting in a significant but not prohibiting increase in power usage. The exact power consumption must be further investigated in order to determine the viability of Approach Curve Matching conclusively. There are however multiple other challenges with Approach Curve Matching. The algorithm relies on the symmetry of wave propagation, ie., that the signal will theoretically be effected the same way by environmental factors between the key and vehicle in both directions, but this may not be so in practice. Furthermore, shifts in discrete sampling may have a compounding negative effect on asymmetry. Due to this method employing a relatively complex algorithm, a large amount of calibration and testing would be required before a viable commercial product could be designed. The exact sampling rate, acceptance threshold, exact comparison algorithm, etc. would also have to be determined through lengthy testing and prototyping. The implementation of such a system into existing PKE systems is

18 3.7. APPROACH CURVE MATCHING not as trivial as Immobility Detection. Therefore, while this thesis highlights the viability and encourages further study of this method it does not investigate it in depth.

19

Chapter 4

Implementation

The following chapter presents the implementation of the PKE system. It details and motivates chosen hardware, software architecture, software logic and, finally, presents the results obtained.

4.1 Hardware

The following sections describe the hardware setup for the implementation of an Immobility Detection enhanced PKE system. While the exact setup is not identical to most commercial systems, it is equivalent in all aspects that could affect the defense systems effectiveness and implementability. Decisions regarding hardware selection were based primarily on suitability for the project, economic viability, and ease of use.

4.1.1 Microcomputer The microcomputer used was the Raspberry Pi Zero W: a low-cost single-board computer with inbuilt wireless (Wi-Fi and Bluetooth) capabilities. The computa- tional power required for the authentication protocol and Bluetooth communication is very low with essentially only the encryption being a processor heavy operation. The actual chips used commercially in key fobs and on-board computers are natu- rally highly optimised for cost and performance but the Raspberry Pi is suitable for a proof of concept due to its ease of use. Furthermore it has an abundance of General Purpose Input/Output (GPIO) pins which make it preferable for prototyping.

4.1.2 Bluetooth Module The Raspberry Pi Zero W has an inbuilt Cypress CYW43438 chip for wireless communication using Wi-Fi and Bluetooth, which was used. The project did not use the low-energy capability of Bluetooth 4.1 as power consumption was not considered for the physical prototype, but the implementation would not differ significantly with BLE. RSSI was used for distance measurements.

21 CHAPTER 4. IMPLEMENTATION

4.1.3 Accelerometer

The accelerometer used was a MPU6050 sensor which includes a 3-axis gyroscope and accelerometer. Communication with the chip is done through the System Man- agement Bus (SMBus) - a commonly used serial bus for peripherals.

Figure 4.1: Connection diagram for the MPU6050 accelerometer to Raspberry Pi Zero. (Figure made with Fritzing)

Commercial products will likely employ more cost effective and resilient compo- nents such as the AIS2DW12 discussed in Chapter 3; however, the selected GY-521 is functionally identical. Since Immobility Detection does not require extremely high precision (any eventual uncertain output range during slight vibrations can be filtered with simple hysteresis) the selection of this component is not of particularly high importance. The connection diagram of the accelerometer to the Raspberry Pi can be seen in Figure 4.1. Ideally, the accelerometer would be checked only upon entering the required range from the car in order to establish if the key if in motion (since several readouts may be necessary this range could actually be slightly further than the distance needed for unlocking the vehicle). Upon entering range the key must, per definition, be moving (unless an attacker is accessing the key); therefore, it is enough to activate the accelerometer then. However, due to a technical malfunction of the sensor during the project, where one of the three axes of acceleration measurements were lost, a workaround was implemented with the sensor active indefinitely and reporting movement upon fluctuation of the readout. Since power consumption and processing speed was not a priority of this project the alternative implementation did not have an impact on the outcome in any way.

4.1.4 Locking and Servo Motor

Due to project limitations, the locking mechanism was present only for demon- strational purposes. Since the lock system is completely separate from the PKE system, the complexity of the mechanism does not affect the underlying access con- trol. The locking demonstrator uses a MG90S micro servo whose position indicates

22 4.2. SOFTWARE the locked/unlocked state of the vehicle. The servo control is achieved through Pulse Width Modulation (PWM) on the Raspberry Pi’s GPIO pins. A duty cycle of 2% at 50Hz is used for setting the servo at 0°and 13% for rotating to 180°.A proposed CAD model can be seen in Appendix D. The models for the servo and horn were sourced online, while the rest of the mechanism was designed in Solid Edge [36, 37].

4.2 Software

The following sections describe the software setup for the implementation of an Immobility Detection enhanced PKE system. The implementation was done in three releases. One for the base functionality consisting of the software needed for a PKE system without Immobility Detection, one with implemented Immobility Detection, and finally implementing the demonstational locking mechanism. While certain features were omitted or greatly simplified, such as the encryption algorithm or excluding the initial button press before authentication begins often included in commercial systems, care was taken in order to ensure that the general software architecture and authentication protocol allowed for the implementation of such features. These include support for multiple keys and active RKS. The source code was written in Python and can be found in Appendices E and F.

Figure 4.2: Activity diagram of the unlocking process for the improved PKE system with Immobility Detection. (Figure made with draw.io)

23 CHAPTER 4. IMPLEMENTATION

4.2.1 Logic

The logic underlying the PKE system is based on existing commercial systems to a large degree. The Immobility Detection is a defence system easily implemented distinct from the base functionality which is, with the exception of some omitted features, identical to those described in Section 2.1. Figure 4.2 depicts an activity diagram for unlocking the vehicle. The addition of Immobility Detection inserts an extra control after checking for proximity of the vehicle - using RSSI - where depending on the accelerometer readout either the authentication proceeds or the user is alerted to a potential attack. The alert can take any form, in this project it was sufficient to use a command-line message, but commercial systems would likely use an audible alert from the key fob.

4.2.2 Authentication Protocol

The authentication protocol for a successful unlocking by the intended user can be seen in the sequence diagram in Figure 4.3. The protocol can be described by the following steps:

1. The vehicle broadcasts a request for connection with its paired keys periodi- cally, which is answered if the key is within a given range. This range may be the same or larger than the range needed for actually unlocking the vehicle, ie., around one meter. The range is determined using RSSI, but can also be done by measuring Rx power.

2. Upon successful connection the car transmits a wake-up to the key - this step can be combined with connection but this project’s implementation separates the two.

3. The key then assesses the accelerometer readouts and determines if it is in sleep mode. If so, it alerts the user and authentication may not proceed.

4. Assuming a normal use case, where the key is not in sleep mode, it confirms the wake-up.

5. The vehicle generates a cryptographic nonce and sends the challenge. While the key replies it calculates the expected response.

6. The key receives the challenge and calculates the response using its private hardware key, and transmits it back to the vehicle.

7. The vehicle compares the received response to the expected response and, assuming a match, unlocks the vehicle.

24 4.2. SOFTWARE

Figure 4.3: Sequence diagram of a successful unlocking sequence. (Figure made with draw.io)

4.2.3 Software Architecture

The software for the PKE system is built-up by the software in the vehicle’s on- board computer and that of the key fob. Python modules used worth mentioning are: PyBluez [38] for interfacing with the Pi’s Bluetooth resources and smbus for SMBus access through I2C for the accelerometer. The software was highly mod- ularized - primarily for easy integration of new features - as well as for ease of development. Multi-threading was used for RSSI and accelerometer monitoring with periodic callbacks to the main Bluetooth and sleep-mode control modules to update the state of the key fob. The key fob’s software, see Appendix E, consisted of a main control module implementing the protocol logic with more specific functions delegated to other

25 CHAPTER 4. IMPLEMENTATION modules. The Bluetooth module implemented all necessary functions for commu- nication such as: establishing connection, cleaning up Bluetooth sockets, and send- ing/receiving messages. The sleep-mode module similarly implemented all necessary functionality for monitoring the accelerometer and determining sleep-mode. The software of the vehicle’s on-board computer is much simpler. It is a two state machine with a series of events as transition criteria from one state to the other (the authentication protocol). The functions for the protocol are trivial, see Figure 4.3 and Appendix F.

4.2.4 Encryption

For the purposes of this project no secure encryption algorithm was implemented. As encryption does not influence the Immobility Detection system and the under- lying logic it was deemed unnecessary. However, due to the protocol implementing a mock challenge-response, an unencrypted and non-random placeholder for a po- tential real challenge-response, the addition of such a feature would not alter the architecture of the software as a whole. Similarly, other desired features can easily be added to the system due to its modularity and regard for compatibility with omitted features.

4.3 Results

After developing the software and constructing the setup, as seen in Figure 4.4, the effectiveness of the implemented PKE system was assessed using a set of test cases for common use cases, found in Appendix G.

Figure 4.4: Prototype setup of the implemented PKE system with the key fob and accelerometer (left) and on-board computer and lock (right).

26 4.3. RESULTS

These include: the key entering communication range without getting close enough to unlock the vehicle; a complete unlocking procedure; complete locking procedure; the key entering sleep mode while in the vehicle; and a relay attack on the car while the key is in sleep-mode. A summary of the testing is displayed in Table 4.1. All tests were performed successfully, with the system behaving as desired. It can be concluded that the PKE system worked as expected. While due to RSSI inaccuracies inherent with Bluetooth the effective range was variable, the system’s response time was, from an end user perspective, immediate. The Immobility Detection system successfully protected against relay attacks while not impeding the function of the base PKE system. The effectiveness of the implemented defense is discussed further in Chapter 5.

Table 4.1: Table summarising acceptance testing for Immobility Detection enhanced PKE

Test Pass/ Name Description Expected Outcome ID Fail Key entering connection KeyNotIn- Connection established, 1 range but not unlock Pass Range car locked range Succesful- Key from rest to unlock- 2 Vehicle unlocked Pass Unlock ing car SleepMode- Key enters sleep while 3 Car remains unlocked Pass WhileInCar in unlocked car Key from sleep-mode in Succesful- 4 unlocked car to locked Car locked Pass Lock car Relay attack while key Car remains locked, key 5 RelayAttack Pass far from car in sleep alerts

However, the execution of the project also revealed insights crucial to this the- sis. It was determined that existing PKE systems without any advanced form of protection against relay attacks can benefit from Immobility Detection. Developing such a defense system can be done to some extent separate from the existing one, allowing for smooth integration while maintaining a low level of complexity, see Section 4.2. Since the core functionality of the PKE system does not necessarily need to be altered to accommodate Immobility Detection, as opposed to for example distance bounding which requires an overhaul of the hardware as well as the proto- col, the development and integration is relatively trivial. The hardware adjustment required is minimal - the currently employed processor and RFID transmitter may be kept - needing essentially only the addition of an accelerometer. Accelerometers

27 CHAPTER 4. IMPLEMENTATION for similar applications are already on the market, as described in Chapter 3, and are cost efficient. Furthermore, the addition of such a system was deemed to be insignificant or even positive - depending on exact implementation - on battery life, an important aspect in commercial applications. The level of effectiveness of Bluetooth in the place of RFID based communication did not have a notable affect on this project. However, some interesting trends could be observed. The project used RSSI for measuring proximity to the vehicle, a critical feature for both security and user comfort. There were, however, major flaws detected with this. RSSI in general is not intended for absolute distance measurements. While for the purposes of this project the test environment could be limited for accurate calibration of the RSSI range, environmental factors in a commercial application would affect the readout significantly. This effect was observed to be so strong that the system designed - in its current form - could not function effectively in a varying environment. Objects in the path of the key fob, surrounding metallic objects, any covering material such as clothes, a bag, or even a person’s hand all have a significant impact on the RSSI value. While Bluetooth, or rather BLE, as a technology for PKE systems may yet be ideal, see Section 2.3.2, this project observed that using RSSI is not viable.

28 Chapter 5

Discussion

Evaluation of Immobility Detection This project has designed and developed a proof of concept implementation of a PKE system with Immobility Detection as a form of protection against relay attacks. It was observed that even a relatively simple Immobility Detection system is extremely effective against relay attacks on stationary key fobs and that low cost accelerometers provide sensor data satisfac- tory for ensuring sleep-mode is entered when desirable. However, this system does not protect against all instances of relay attacks, as mobile keys are still vulnerable. With recent affordable and high range relay devices these thefts may become more common, posing a risk even for Immobility Detection enhanced PKE systems. Nev- ertheless, the clearly defined effective range of this system is an advantage in and of itself, allowing for manufacturers to clearly outline what the system achieves. It was shown that the development of Immobility Detection is simple and can be easily integrated into existing PKE systems without requiring substantial changes to existing hardware or software. It was further found that such a system can be achieved in a cost effective manner with existing low cost components. If power usage optimization is desired then implementations exist where this system may increase battery life. While some parameters, such as the timer for entering sleep mode and exact vibration thresholds, must be calibrated with regard for end use, the commercial development time of such a system is significantly shorter than many other proposed solutions and has little to no associated risks. Therefore, manufacturers could begin manufacturing newer car models with Immobility Detection in a short time-frame, while investigating other, more long-term, solutions.

Alternative Defenses Multiple proposed defenses have been described and ana- lyzed with many lacking consideration for implementability, commercial viability, or cost, while others fall short in terms of security. It is deemed that two other meth- ods promise potential. While distance bounding may be far from a commercial application, requiring further study not only on the protocol but also on hardware, integration into a printed circuit board, and reliability, recent advances in all of the

29 CHAPTER 5. DISCUSSION above aspects are promising. Such a solution would be a large improvement on cur- rent access control. The second method proposed by this thesis - Approach Curve Matching - may also provide considerable increase in security for PKE systems. This defence system, however, requires substantial research before its feasibility can be determined.

Viability of Bluetooth LE for PKE While this thesis concluded that Bluetooth RSSI measurements - at least using the setup in this project - are not reliable enough for PKE applications, Bluetooth as a technology may yet be viable. The power usage of BLE is very low, having been developed for similar applications, which lends itself to access control. Albeit RSSI may not be ideal for PKE, there are novel ways of distance measurement being developed, some even specifically for the automotive industry as discussed in Section 2.3.2. The added advantage of enabling access sharing using mobile phones greatly increases the attractiveness of this technology.

Additional Security Features There are a variety of added precautionary fea- tures that can contribute to an overall safer PKE system. Theft detection, such as that implemented in this project, whereby an attempted attack is not only foiled but alerted against, can increase the risk for attackers and thereby limit attempts. Moreover, access control restrictions upon failed unlock attempts can reduce the opportunity for an attacker to retry an attempted theft, use a different method, or even gather data on the protocol to be used to fine tune the attack. Since all lock systems contain parallel active keyless entry, in the case of an erroneous attempt by the intended user this additional system can still used to unlock the car. Merely the addition of an audible signal from the key fob, as is already present on the vehicle side, may provide some protection against theft. Meanwhile, generally stricter tim- ing constraints for the authentication protocol protect against attacks with more rudimentary equipment or those over long range where potentially time intensive demodulation and modulation of the signal is often needed. Furthermore, for legal proof of theft - in an insurance claim for example - it may be advisable for the key and vehicle to store a log of recent unlocking procedures.

30 Chapter 6

Conclusion

This thesis investigated, implemented, and assessed an Immobility Detection en- hanced PKE system for relay attack resistance as well as various other proposed defence mechanisms. It can be concluded that, albeit limited to the case of a stationary key, Immobility Detection is a highly effective method of protection. Ad- ditionally, the implementation of such a system, as opposed to other proposals, in existing PKE systems is found to be cost efficient, trivial in nature, and not highly time consuming. In combination with the introduction of other defensive measures, Immobility Detection can greatly increase the security of PKE systems. While this thesis focuses specifically on PKE systems for vehicles, similar technology can used for other access control applications. The conclusions of this thesis can be used to motivate further research as well as direct action by vehicle manufacturers.

31

Bibliography

[1] Statistics Sweden. (2020, Jan) Registered vehicles January 2006–December 2019. [Online]. Available: https://www.scb.se/en/finding-statistics/statistics- by-subject-area/transport-and-communications/road-traffic/registered- vehicles/pong/tables-and-graphs/registered-vehicles/ [Accessed: 2020-02-02].

[2] ——, “Preliminary population statistics 2019,” https://www.scb.se/ en/finding-statistics/statistics-by-subject-area/population/population- composition/population-statistics/pong/tables-and-graphs/monthly- statistics--the-whole-country/preliminary-population-statistics-2019/, Statis- tics Sweden, Tech. Rep., Jan 2020, [Online; accessed 2020-02-16].

[3] L. Huang, Q. Yang, Q. Gu, W. Zhang, H. Shan, J. Li, and Y. Zeng, Inside Radio: An Attack and Defense Guide. Springer Nature and Publishing House of Electronics Industry, Beijing, Mar 2018. doi: https://doi.org/10.1007/978- 981-10-8447-8

[4] S. Rizvi, J. Imler, L. Ritchey, and M. Tokar, “Securing PKES against Relay Attacks using Coordinate Tracing and Multi-Factor Authentication,” in 2019 53rd Annual Conference on Information Sciences and Systems (CISS), Mar 2019. doi: https://doi.org/10.1109/CISS.2019.8692790. ISSN null pp. 1–6.

[5] A. I. Alrabady and S. M. Mahmud, “Analysis of attacks against the security of keyless-entry systems for vehicles and suggestions for improved designs,” IEEE Transactions on Vehicular Technology, vol. 54, no. 1, pp. 41–50, Jan 2005. doi: https://doi.org/10.1109/TVT.2004.838829

[6] M. G¨ulsever, “A Study on Vulnerabilities in Connected Cars,” B.Sc. Thesis, KTH, School of Electrical Engineering and Computer Science (EECS), Jun 2019.

[7] J. Wang, K. Lounis, and M. Zulkernine, “CSKES: A Context-Based Se- cure Keyless Entry System,” in 2019 IEEE 43rd Annual Computer Soft- ware and Applications Conference (COMPSAC), vol. 1, Jul 2019. doi: https://doi.org/10.1109/COMPSAC.2019.00120. ISSN 0730-3157 pp. 817–822.

33 BIBLIOGRAPHY

[8] A. Francillon, B. Danev, and S. Capkun, “Relay Attacks on Passive Keyless Entry and Start Systems in Modern Cars.” IACR Cryptology ePrint Archive, vol. 2010, p. 332, Jan 2010. doi: https://doi.org/10.3929/ethz-a-006708714

[9] W. Choi, M. Seo, and D. Hoon Lee, “Sound-Proximity: 2-Factor Authentication against Relay Attack on Passive Keyless Entry and Start System,” Journal of Advanced Transportation, Jan 2018. doi: https://doi.org/10.1155/2018/1935974

[10] K. Leuven. (2018, Sep) Fast, Furious and Insecure: Passive Keyless Entry and Start in Modern Supercars. [Online]. Avail- able: https://www.esat.kuleuven.be/cosic/fast-furious-and-insecure-passive- keyless-entry-and-start-in-modern-supercars/ [Accessed: 2020-02-16].

[11] T. Gerber. (2019, Mar) SAPD: Car thieves using technology to hack key fobs, steal vehicles. [Online]. Available: https://www.ksat.com/news/2019/03/12/ sapd-car-thieves-using-technology-to-hack-key-fobs-steal-vehicles/ [Accessed: 2020-03-16].

[12] The Japan Times. (2019, 01) Osaka police say thefts of vehicles using ’relay attack’ technique on rise in area. [Online]. Available: https://www.japantimes. co.jp/news/2019/01/05/national/crime-legal/osaka-prefecture-police-say-car- thefts-using-relay-attack-technique-rise-area/#.XrWpskBuKP [Accessed: 2020-03-16].

[13] Y. Z. Y. Li. (2017, 10) Car keyless entry system attack. [Online]. Available: https://conference.hitb.org/hitbsecconf2017ams/materials/ [Accessed: 2020- 02-02].

[14] Lexus. What sized battery is used in Lexus remote keys? [On- line]. Available: https://lexus2.custhelp.com/app/answers/detail/a id/8347/ ∼/what-size-battery-is-used-in-lexus-remote-keys%3F [Accessed: 2020-02-21].

[15] ——. Lexus 2018 NX300H Owner’s Manual (OM78212U). [Online]. Available: https://drivers.lexus.com/t3Portal/document/om-s/OM78212U/ pdf/OM78212U.pdf [Accessed: 2020-02-21].

[16] J. Rodriguez. (2016, Oct) Long-range RFID emitter an- tennas for passive keyless entry systems. [Online]. Avail- able: https://www.eenewsautomotive.com/news/long-range-rfid-emitter- antennas-passive-keyless-entry-systems [Accessed: 2020-03-16].

[17] Sheng Zhou and J. K. Pollard, “Position measurement using bluetooth,” IEEE Transactions on Consumer Electronics, vol. 52, no. 2, pp. 555–558, 2006. doi: https://doi.org/10.1109/TCE.2006.1649679

34 BIBLIOGRAPHY

[18] Imec. (2018, Nov) Imec demonstrates first secure passive keyless entry solution for automotive using Bluetooth Low Energy. [Online]. Avail- able: https://www.imec-int.com/en/articles/imec-demonstrates-first-secure- passive-keyless-entry-solution-for-automotive-using-bluetooth-low-energy [Ac- cessed: 2020-04-21]. [19] S. K. J. K. Gyu-Ho Kim, Kwan-Hyung Lee, “Vehicle Relay Attack Avoidance Methods Using RF Signal Strength,” Communications and Network, Apr 2013. doi: https://doi.org/10.4236/cn.2013.53B2103 [20] National Coordination Office for Space-Based Positioning, Navigation, and Timing. (2017) GPS accuracy. [Online]. Available: https://www.gps.gov/ systems/gps/performance/accuracy/ [Accessed: 2020-02-16]. [21] U-blox AG. (2019) ZOE-M8B, Ultra-small, super low power u-box M8 GNSS SiP module. [Online]. Available: https://www.u-blox.com/en/docs/ UBX-17035164 [Accessed: 2020-02-19]. [22] S. Labs, WF200 Data Sheet: Wi-Fi©Network Co-Processor, Jan 2020. [Online]. Available: https://www.silabs.com/support/resources.p-wireless wi- fi wf200-series-2-wi-fi-transceiver-socs [23] P. K. G. F. D. M. A. S. G. A. A. Z. A. T. Christian, “Driving and park- ing patterns of European car drivers - a mobility survey.” Dec 2012. doi: https://doi.org/10.2790/70746 [24] G. P. Hancke and M. G. Kuhn, “An RFID Distance Bounding Protocol,” in First International Conference on Security and Privacy for Emerging Areas in Communications Networks (SECURECOMM’05), Sep. 2005. doi: https://doi.org/10.1109/SECURECOMM.2005.56 pp. 67–73. [25] K. B. Rasmussen and S. Capkun,ˇ “Realization of RF Distance Bound- ing,” in Proceedings of the 19th USENIX Conference on Security, ser. USENIX Security’10. USA: USENIX Association, Aug 2010. doi: https://doi.org/10.5555/1929820.1929854 p. 25. [26] A. Mitrokotsa, C. Onete, and S. Vaudenay, “Mafia fraud attack against the RCˇ Distance-Bounding Protocol,” in 2012 IEEE International Confer- ence on RFID-Technologies and Applications (RFID-TA), Nov 2012. doi: https://doi.org/10.1109/RFID-TA.2012.6404571 pp. 74–79. [27] D. Singel´eeand B. Preneel, “Security Analysis of the Rasmussen-Capkun CRCS Distance Bounding Protocol,” Jan 2010, p. 13. [28] T. Yang, L. Kong, W. Xin, J. Hu, and Z. Chen, “Resisting relay attacks on vehicular Passive Keyless Entry and start systems,” in 2012 9th Inter- national Conference on Fuzzy Systems and Knowledge Discovery, 2012. doi: https://doi.org/10.1109/FSKD.2012.6234155 pp. 2232–2236.

35 BIBLIOGRAPHY

[29] M. J. Hussain, L. Lu, and H. Zhu, “TIGHT: A Cross-Layer RF Distance Bounding Realization for Passive Wireless Devices,” IEEE Transactions on Wireless Communications, vol. 14, no. 6, pp. 3076–3085, Feb 2015. doi: https://doi.org/10.1109/TWC.2015.2400440

[30] K. B. Rasmussen. (2010, Aug) Realisation of RF Distance Bounding. [Online]. Available: https://www.usenix.org/conference/usenixsecurity10/realization- rf-distance-bounding Accessed: 2020-02-23.

[31] Ford Motor Company. Motion Sensing Key Fob. [Online]. Available: https://www.ford.co.uk/owner/resources-and-support/ask-ford/ technical-and-maintenance/car-features/motion-sensing-key-fob [Accessed: 2020-05-09].

[32] J. Edgren, “Den smarta nyckeln stoppar biltjuvarna [in Swedish],” Ny Teknik, 11 2017. [Online]. Available: https://www.nyteknik.se/fordon/den-smarta- nyckeln-stoppar-biltjuvarna-6883404 [Accessed: 2020-05-09].

[33] STMicroelectronics. (2019, Jun) AIS2DW12, MEMS digital output motion sensor: ultra-low-power 3-axis accelerometer for automotive applications . [Online]. Available: https://www.st.com/en/mems-and-sensors/ais2dw12.html [Accessed: 2020-02-15].

[34] Argenox Technologies. (2018, Jan) A Guide to Selecting a Bluetooth Chipset. [Online]. Available: https://www.argenox.com/library/bluetooth-low-energy/ a-guide-to-selecting-a-bluetooth-chipset/ [Accessed: 2020-07-05].

[35] Texas Instruments Incorporated. (2006) CC1050 Single Chip Very Low Power RF Transmitter. [Online]. Available: https://www.ti.com/product/CC1050/ technicaldocuments [Accessed: 2020-07-05].

[36] M. Ghanbari. TowerPro MG90S Micro Servo. [Online]. Available: https: //grabcad.com/library/towerpro-mg90s-micro-servo-1 [Accessed: 2020-05-19].

[37] Rudimal. Microservo mg90s sg90 horn. [Online]. Available: https://grabcad. com/library/microservo-mg90s-sg90-horn-1 [Accessed: 2020-05-19].

[38] A. Haung. pybluez.

36 Appendices

A ZOE-M8B GPS Module Data-sheet (excerpt)

37 

ZOE-M8B Ultra-small, super low power u-blox M8 GNSS SiP module Data Sheet

Abstract Technical data sheet describing the ZOE-M8B ultra-small and ultra-low power GNSS SiP modules with Super-E mode. Power consumption is as low as 12 mW with Super-E mode. The modules provide a fully integrated, complete solution, reducing design and test efforts. They are ideal for passive antennas, due to built-in SAW and LNA and have high accuracy thanks to concurrent reception of up to 3 GNSS.

www.u-blox.com UBX-17035164 - R04 ZOE-M8B - Data Sheet

Document Information

Title ZOE-M8B Subtitle Ultra-small, super low power u-blox M8 GNSS SiP module Document type Data Sheet Document number UBX-17035164 Revision and date R04 13-Aug-2019 Document status Production Information

Product status Corresponding content status In Development / Objective Specification Target values. Revised and supplementary data will be published later. Prototype Engineering Sample Advance Information Data based on early testing. Revised and supplementary data will be published later.

Initial Production Early Production Information Data from product verification. Revised and supplementary data may be published later.

Mass Production / Production Information Document contains the final product specification. End of Life

This document applies to the following products:

Product name Type number ROM/FLASH version PCN reference ZOE-M8B ZOE-M8B-0-10 ROM SPG 3.51 N/A

u-blox or third parties may hold intellectual property rights in the products, names, logos and designs included in this document. Copying, reproduction, modification or disclosure to third parties of this document or any part thereof is only permitted with the express written permission of u-blox. The information contained herein is provided “as is” and u-blox assumes no liability for its use. No warranty, either express or implied, is given, including but not limited to, with respect to the accuracy, correctness, reliability and fitness for a particular purpose of the information. This document may be revised by u-blox at any time without notice. For the most recent documents, visit www.u-blox.com.

Copyright © u-blox AG.

UBX-17035164 - R04 Document Information Page 2 of 31 Production Information ZOE-M8B - Data Sheet

1.3 GNSS Performance

Parameter Specification Receiver type 72-channel u-blox M8 engine GPS L1C/A, QZSS L1C/A, QZSS L1-SAIF, GLONASS L1OF, BeiDou B1I , Galileo1 E1B/C, SBAS L1C/A: WAAS, EGNOS, MSAS, GAGAN Operational limits2 Dynamics ≤ 4 g Altitude 50,000 m Velocity 500 m/s Velocity accuracy3 Continuous mode 0.05 m/s Super-E mode, 0.2 m/s Super-E mode, 0.4 m/s performance power save setting6 setting (default)6 Heading accuracy3 Continuous mode 0.3 degrees Super-E mode, 1 degree Super-E mode, 2 degrees performance power save setting6 setting (default)6 GNSS GPS & GLONASS GPS GLONASS BeiDou Galileo Horizontal position accuracy in Continuous mode4 2.5 m 2.5 m 4.0 m 3.0 m TBC 5 Horizontal position accuracy in Super-E mode, 3.5 m 3.0 m 9.0 m N/A not supported performance setting (default)4, 6 Horizontal position accuracy in Super-E mode, 4.0 m 3.5 m 10.5 m N/A not supported power save setting4, 6 Max navigation update rate in Continuous mode7 10 Hz 18 Hz 18 Hz 18 Hz 18 Hz

Max navigation update rate in Super-E mode 4 Hz 4 Hz 4 Hz 4 Hz not supported Time-To-First-Fix8 Cold start 26 s 29 s 30 s 34 s 45 s Hot start 1 s 1 s 1 s 1 s 1 s Aided starts9 2 s 2 s 2 s 3 s 7 s Sensitivity in Continuous Tracking & -167 dBm -166 dBm -166 dBm -160 dBm -159 dBm mode10 Navigation Reacquisition -160 dBm -160 dBm -156 dBm -157 dBm -153 dBm Cold start -148 dBm -148 dBm -144 dBm -143 dBm -138 dBm Hot start -157 dBm -157 dBm -154 dBm -155 dBm -151 dBm Sensitivity in Super-E mode10 Tracking & -160 dBm -160 dBm -157 dBm -159 dBm not supported Navigation Reacquisition -160 dBm -160 dBm -156 dBm -157 dBm not supported Cold start -148 dBm -148 dBm -144 dBm -143 dBm not supported Hot start -157 dBm -157 dBm -154 dBm -155 dBm not supported

Table 1: ZOE-M8B performance in different GNSS modes (Default: concurrent reception of GPS and GLONASS)

1 Galileo signals can be received reliably only in continuous mode. Galileo should not be enabled in Super-E mode. 2 Assuming Airborne < 4 g platform 3 50% @ 30 m/s 4 CEP, 50%, 24 hours static, -130 dBm, > 6 SVs 5 To be confirmed when Galileo reaches full operational capability 6 Extreme operating temperatures can impact specification. Applications operating near the temperature limits should be tested to ensure the specifications. 7 Rates with SBAS and QZSS enabled for > 98% fix report rate under typical conditions 8 All satellites at -130 dBm, except Galileo at -127 dBm 9 Dependent on aiding data connection speed and latency 10 Demonstrated with a good external LNA

UBX-17035164 - R04 Functional description Page 6 of 31 Production Information ZOE-M8B - Data Sheet

3 Electrical specification ☞ The limiting values given are in accordance with the Absolute Maximum Rating System (IEC 134). Stress above one or more of the limiting values may cause permanent damage to the device. These are stress ratings only, and operation of the device at these or at any other conditions above those given in the Characteristics sections of the specification is not implied. Exposure to limiting values for extended periods may affect device reliability.

☞ Where application information is given, it is advisory only and does not form part of the specification. For more information regarding power management see the ZOE-M8B System Integration Manual [1].

3.1 Absolute maximum rating

Symbol Parameter Min Max Unit

VCC Supply voltage –0.5 3.6 V V_BCKP Supply voltage baseband backup core –0.5 3.6 V

ViRTC Input voltage on RTC_I –0.5 1.6 V

ViDIG Input voltage on Configurable Inputs , RESET_N if VCC < 3.1 V –0.5 VCC+0.5 V Input voltage on Configurable Inputs , RESET_N if VCC > 3.1 V –0.5 3.6 V Prfin RF Input power on RF_IN inband14 0 dBm RF Input power on RF_IN outband15 +15 dBm Ptot Total power dissipation 500 mW Ts Storage temperature –40 +85 °C

Table 8: Absolute maximum ratings ⚠ Stressing the device beyond the “Absolute Maximum Ratings” may cause permanent damage. These are stress ratings only. The product is not protected against overvoltage or reversed voltages. If necessary, voltage spikes exceeding the power supply voltage specification, given in table above, must be limited to values within the specified boundaries by using appropriate protection diodes.

14 Inband = 1525-1650 MHz 15 Outband = 777-915 MHz, 1710-2200 MHz

UBX-17035164 - R04 Electrical specification Page 19 of 31 Production Information ZOE-M8B - Data Sheet

3.2 Operating conditions ☞ The test conditions specified in Table 9 apply to all characteristics defined in this section.

Symbol Parameter Min Typical Max Unit Remarks

Tamb Ambient temperature -40 +25 +85 °C GND Ground 0 V VCC Supply voltage 1.8 V V_BCKP Backup battery supply 1.8 V voltage NFtot Receiver Chain Noise Figure 2.5 dB

Table 9: Test conditions ☞ All specifications are at an ambient temperature of 25°C. Extreme operating temperatures can significantly impact specification values. Applications operating near the temperature limits should be tested to ensure the specification.

3.2.1 DC electrical characteristic ☞ For Power Management Unit (PMU) block diagrams, see the ZOE-M8B System Integration Manual [1].

Symbol Parameter Min Typical Max Unit

V_BCKP Input voltage for backup supply 1.4 3.6 V VCC16 Supply voltage 1.71 1.89 V

Table 10: Power supply pins

Symbol Parameter Condition Min Typical Max Unit

Ileak Leakage current input pins < 1 nA Vil Low level input voltage 0 0.2*VCC V Vih High level input voltage 0.7*VCC VCC+0.5 V Vol Low level output voltage Iol = 4 mA 0.4 V for TXD/SPI MISO, RXD/SPI MOSI, SDA/SPI CS_N, SCL/SPI CLK, D_SEL, PIO11, PIO13/EXTINT, PIO14, PIO15, LNA_EN Voh High level output voltage Ioh = 4 mA VCC-0.4 V for TXD/SPI MISO, RXD/SPI MOSI, SDA/SPI CS_N, SCL/SPI CLK, D_SEL, PIO11, PIO13/EXTINT, PIO14, PIO15, LNA_EN Rpu Pull-up resistor for SDA/SPI 11 kΩ CS_N, SCL/SPI CLK , PIO11, PIO13/EXTINT, PIO14, RESET_N Rpu Pull-up resistor for TXD/SPI 115 kΩ MISO, RXD/SPI MOSI, PIO15, D_SEL

Table 11: Digital IO pins

16 Max 50 mVpp ripple

UBX-17035164 - R04 Electrical specification Page 20 of 31 Production Information ZOE-M8B - Data Sheet

3.2.2 Baseband parameters

Symbol Parameter SiP Condition Min. Typ. Max. Unit

RTC_Fxtal RTC crystal resonant All 32768 Hz frequency RTC_T_start RTC startup time All 0.2 0.35 0.9 sec RTC_Amp 32768 Hz OSC All 50 350 mVpp oscillation amplitude RTC_ESR 32768 Hz Xtal All 100 kΩ equivalent series resistance RTC_CL RTC integrated load All ESR = 80 kΩ 4 7 12 pF capacitance

Table 12: Baseband parameters

3.3 Indicative power requirements Table 13 lists examples of the total system supply current for a possible application.

☞ The values in Table 13 are provided for customer information only as an example of typical current requirements. The values are characterized on samples; actual power requirements can vary depending on firmware version used, external circuitry, number of SVs tracked, signal strength, type of start as well as time, duration and conditions of test.

Parameter Symbol Typ Typ Max Units Condition GPS & GPS GLONASS Max. supply current 17 Iccp 70 mA VCC = 1.8 V Average supply Icc Acquisition19 45 34.5 mA VCC = 1.8 V current 18 Icc Tracking 40 32.5 mA VCC = 1.8 V (Continuous mode) Icc Tracking 8.3 7.3 mA VCC = 1.8 V (Super-E mode, performance setting (default) / 1 Hz) Icc Tracking 6.8 6.3 mA VCC = 1.8 V (Super-E mode, power save setting / 1 Hz) Backup battery I_BCKP 15 uA HW Backup mode, current 20 VCC = 0 V, V_BCKP = 3 V using the RTC crystal SW Backup current I_SWBCKP 20 uA SW Backup mode, VCC = 1.8 V, using the RTC crystal

Table 13: Currents to calculate the indicative power requirements For more information about power requirements, see the ZOE-M8B System Integration Manual [1].

☞ All values in Table 13 are measured at 25 °C ambient temperature.

17 Use this figure to dimension maximum current capability of power supply. Measurement of this parameter with 1 Hz bandwidth. 18 Simulated constellation of 8 satellites is used. All signals are at -130 dBm. 19 Average current from start-up until the first fix. 20 Use this figure to determine required battery capacity.

UBX-17035164 - R04 Electrical specification Page 21 of 31 Production Information ZOE-M8B - Data Sheet

3.4 SPI timing diagrams In order to avoid incorrect operation of the SPI, the user needs to comply with certain timing conditions. The following signals need to be considered for timing constraints:

Symbol Description

SPI CS_N (SS_N) Slave select signal SPI CLK (SCK) Slave clock signal

Table 14: Symbol description

Figure 3: SPI timing diagram 3.4.1 Timing recommendations The recommendations below are based on a firmware running from SQI flash memory.

Parameter Description Recommendation

tINIT Minimum Initialization Time 10 us

tDES Deselect Time 1 ms.

tbit Minimum bit time 1 us (1 MHz max bit frequency)

tbyte Minimum byte period 8 µs (125 kHz max byte frequency)

Table 15: SPI timing recommendations ☞ The values in the above table result from the requirement of an error-free transmission. By allowing just a few errors and disabling the glitch filter, the bit rate can be increased considerably.

3.5 DDC timing diagrams The DDC interface is I2C Fast Mode compliant. For timing parameters consult the I2C standard.

☞ The maximum bit rate is 100 kbit/s. The interface stretches the clock when slowed down while serving interrupts, so real bit rates may be slightly lower.

UBX-17035164 - R04 Electrical specification Page 22 of 31 Production Information B. POWER CONSUMPTION MEASUREMENTS FOR WF(M)200 WI-FI MODULE (EXCERPT) B Power Consumption Measurements for WF(M)200 Wi-Fi Module (excerpt)

45 AN1219: Power Consumption Measurement Setup and Results on WF(M)200

WF(M)200 is a Wi-Fi network co-processor optimized for low- energy consumption. This application note describes how to KEY POINTS perform current consumption measurements and get the lowest • WF200 and WFM200 are optimized for low current consumption with WF(M)200. consumption • Improving WF(M)200 usage for low-current Additionally, this document shows how to achieve accurate measurements using consumption BDR8022 or BRD8023 and provides measurement examples for different use cases. • Performing accurate current This document applies to both WF200 and WFM200. For simplicity, both devices are measurements with BRD8022/BRD8023 referred to as WF(M)200. • Measurement examples

silabs.com | Building a more connected world. Rev. 1.0 AN1219: Power Consumption Measurement Setup and Results on WF(M)200 WF200 and WFM200 Overview

1.3 Power Profiles Definitions

The current consumption on WF(M)200 is highly dynamic and varies significantly depending on the following factors. • Wi-Fi data traffic activity depends on the application. The more transmit and receive data, the higher the consumption. • Wi-Fi Power-save enabled depends on the application. It saves power consumption if the data throughput is low or if the host uses short period of high throughput and no data traffic between them.

Table 1.2. Power States Description

Modes State Definitions

Traffic modes WF(M)200 is associated with an Access Point, handling some traffic in transmitting or in receiving data frames traffic or in listen state (STA and Soft-AP) TX Transmitting Wi-Fi frames

RX Receiving Wi-Fi frames.

Listen Listening to the channel to receive frames or between RX and TX. This is also the de- fault mode if power save is not enabled.

Additional modes when power save is ena- WF(M)200 is associated with an Access Point and set in power save. bled TX, RX and listen states listed above are still valid. (STA only) States below are observed between beacons reception, provided that WUP pin is Low.

These states also occur if there is no activity with the host before association.

Sleep This state is using LP_CLK and switching off the XTAL.

Snooze Occurs when there is no LP_CLK provided to WF(M)200.

Sleep with XO This state is using LP_CLK but maintains XTAL oscillator active and switching off the XTAL.

Idle modes WF(M)200 is shut down. Resuming operation requires a complete start-up sequence triggered by a rising edge on RESETn pin. (STA and Soft-AP) Shut-down mode Occurs when the host has sent the HIF message requesting the WF(M)200 to switch in Shutdown mode. Achieved only when WUP pin is Low.

Reset mode Occurs when RESETn pin is set low.

1.4 Host Interface (SPI/SDIO)

WF(M)200 can be controlled by an MCU or SoC using either SPI or SDIO (upon SDIO_DAT2/HIF_SEL pin state during the rising edge of RESETn) through the host interface.

The SPI/SDIO clock frequency has an impact on consumption during sleep. As a result, during this state, when possible, the lowest consumption is achieved when the clock is stopped. Moreover, when the wake-up is set to high to exchange message between the host and the WF(M)200, use the highest possible serial clock to reduce this duration. Note: With Linux driver on Raspberry Pi, it is not possible to get the lowest current consumption in sleep state with SDIO interface because the serial clock is not stopped. As a result, the measurements presented in 3. Measurement Setup use the SPI interface.

1.5 RESETn

WF(M)200 RESETn pin has an internal pull-up (43 Kohm typical).

This pin should be kept high when in Shutdown mode to achieve the lowest current consumption. silabs.com | Building a more connected world. Rev. 1.0 | 5 AN1219: Power Consumption Measurement Setup and Results on WF(M)200 Measurement Summary

2. Measurement Summary

Static use cases for current consumption are mentioned in the table below.

These current consumptions are detailed in the data sheet.

Dynamic use cases: • Power save mode when associated under DTIM provides the WF(M)200 average current consumption when there is no TX/RX of data (only receiving Beacons with the DTIM interval and using the sleep state). The current consumption for DTIM1, DTIM3, and DTIM10 is described in the data sheet. • Time and consumption during boot and firmware download • Time and consumption during scan: An active scan is performed on channels 1 up to 11 and a passive scan on channel 12 up to 14 • Time and consumption during Association to an Access Point: The current consumption to get the association with a selected Ac- cess Point • Consumption during data traffic: Low bit rate and short burst of high bit rate, ping current consumption

All current consumption figures provide a better understanding for the global consumption of the WF(M)200 according to the targeted application.

The table below includes a summary of measurements detailed in the following sections:

Static power states:

Table 2.1. Current Consumption Summary for Static States

Use Case Typical current consumption at 3.3 V Comments

TX burst 154.4 mA Depends on the constellation and code rate used in TX and depending of the maximum power allowed

RX burst 41.8 mA

Listen 45.4 mA

Sleep 24.33 µA Depends on the WF(M)200 parts used (some variations are possible)

Sleep with XO ON 438.4 µA

Snooze (No LP_CLK) 1.48 mA

Shutdown ~513 nA WUP low and RESETn stay high

Reset ~75.5µA When RESETn is low. Depends on the in- ternal pull-up resistor in the WF(M)200 part.

Dynamic use cases:

Table 2.2. Current Consumption Summary for Dynamic States

Use Case Measurement Duration Averaged current consump- Comments tionat 3.3 V

Wi-Fi Power save DTIM1 1.02 s ~927 μA Can depend on the Access Point and Wi-Fi context.

Wi-Fi Power save DTIM3 2.45 s ~327 μA Can depend on the Access Point and Wi-Fi context.

Wi-Fi Power save DTIM10 4.1 s ~115 μA Can depend on the Access Point and Wi-Fi context.

Firmware download 264.16 ms ~16.38 mA Depends on the SPI/SDIO clock and firmware size.

silabs.com | Building a more connected world. Rev. 1.0 | 7 AN1219: Power Consumption Measurement Setup and Results on WF(M)200 Measurement Summary

Use Case Measurement Duration Averaged current consump- Comments tionat 3.3 V

Wi-Fi Scanning 951.26 ms ~51.76 mA Can depend on the Access Point and Wi-Fi context.

Wi-Fi association 31.2 ms ~59.64 mA Can depend on the Access Point.

Host to WF(M)200 SPI ex- 2 ms ~7.8 mA Depends on the SPI/SDIO clock change (when no Wi-Fi activity and exchange frame length. during sleep)

Ping traffic with 1 packet per 5 s ~7.36 mA Can depend on the Access second in DTIM1 (1 ICMP pack- Point and Wi-Fi context. et of 64 bytes)

UDP downstream traffic of 100 13.2 s ~5.6 mA Can depend on the Access kbps in DTIM3 with burst profile Point and Wi-Fi context. It de- use case 1 pends also on the burst profile.

UDP downstream traffic of 100 10.4 s ~1.91 mA Can depend on the Access kbps in DTIM3 with burst profile Point and Wi-Fi context. It de- use case 2 pends also on the burst profile.

UDP upstream traffic of 100 11 s ~6.5 mA Can depend on the Access kbps in DTIM3 with burst profile Point and Wi-Fi context. It de- use case 1 pends also on the burst profile.

UDP upstream traffic of 100 10.5 s ~1.93 mA Can depend on the Access kbps in DTIM3 with burst profile Point and Wi-Fi context. It de- use case 2 pends also on the burst profile.

Note: To optimize power consumption in DTIM modes, the frequency drift of LP_CLK should be within 1 second lower than +-100 ppm.

silabs.com | Building a more connected world. Rev. 1.0 | 8 APPENDICES

C AIS2DW12 Accelerometer Data-sheet (excerpt)

50 AIS2DW12

MEMS digital output motion sensor: ultra-low-power 3-axis accelerometer for automotive applications Datasheet - production data Description

The AIS2DW12 is an ultra-low-power three-axis linear accelerometer which leverages on the robust and mature manufacturing processes already used for the production of micromachined accelerometers and designed to address non- safety automotive applications. LGA-12 (2x2x0.93 mm³) The AIS2DW12 has four different ultra-low-power modes, two user-selectable full scales (2g/4g) Features and is capable of measuring accelerations with output data rates from 1.6 Hz to 100 Hz.  AEC-Q100 qualified The AIS2DW12 has an integrated 32-level first-in,  Supply voltage, 1.62 V to 3.6 V first-out (FIFO) buffer allowing the user to store  Independent IO supply and supply voltage data in order to limit intervention by the host compatible processor.  Ultra-low-power mode consumption down to The embedded self-test capability allows the user 380 nA @1.6 Hz to check the functioning of the sensor in the final application.  ±2g/±4g dynamically selectable full scales  High-speed I²C/SPI digital output interface The AIS2DW12 has a dedicated internal engine to process motion and acceleration detection  2 independent programmable interrupts including free-fall, motion and no-motion, wakeup,  Single data conversion on demand activity/inactivity and 6D/4D orientation.  16-bit data output The AIS2DW12 is available in a small thin plastic  Embedded temperature sensor land grid array package (LGA) and it is guaranteed to operate over an extended  Self-test temperature range from -40 °C to +85 °C.  32-level embedded FIFO

 10000 g high shock survivability Table 1. Device summary  ECOPACK, RoHS and “Green” compliant Temp. range Order codes Package Packaging [°C]

Applications AIS2DW12 -40 to +85 LGA-12 Tray Tape and  Car key applications AIS2DW12TR -40 to +85 LGA-12 reel  Inclination / orientation detection  Motion-activated functions  Gesture recognition  Free-fall detection  Smart power saving

June 2019 DocID031240 Rev 4 1/60

This is information on a product in full production. www.st.com Mechanical and electrical specifications AIS2DW12

2.2 Electrical characteristics

Table 5. Electrical characteristics @ Vdd = 3.0 V, T = -40°C to +85°C unless otherwise noted (1) Symbol Parameter Test conditions Min. Typ.(2) Max. Unit

Vdd Supply voltage 1.62 3.6 V Vdd_IO I/O pins supply voltage(3) 1.62 Vdd+0.1 V ODR 100 Hz 5 @ Vdd = 1.8 V(4) ODR 50 Hz 3 @ Vdd = 1.8 V(4) ODR 12.5 Hz 1 @ Vdd = 1.8 V(4) ODR 1.6 Hz (4) 0.38 Current consumption in @Vdd = 1.8 V IddLP μA Power Mode 1 ODR 100 Hz 6.5 12.0 @ Vdd = 3 V ODR 50 Hz 3.7 6.4 @ Vdd = 3 V(4) ODR 12.5 Hz 1.3 2.9 @ Vdd = 3 V(4) ODR 1.6 Hz 0.67 1.9 @ Vdd = 3 V(4) (4) Current consumption @ Vdd = 1.8 V 50 Idd_PD nA in power-down @ Vdd = 3 V 100 950

VIH Digital high-level input voltage 0.8*Vdd_IO V

VIL Digital low-level input voltage 0.2*Vdd_IO V (5) VOH Digital high-level output voltage IOH = 4 mA VDD_IO - 0.2 V (5) VOL Digital low-level output voltage IOL = 4 mA 0.2 V 1. The product is factory calibrated at 3.0 V. The operational power supply range is from 1.62 V to 3.6 V. 2. Typical specifications are not guaranteed. 3. It is possible to remove Vdd maintaining Vdd_IO without blocking the communication busses. In this condition the measurement chain is powered off. 4. Verified at characterization level in Power Mode 1 configuration. 5. 4 mA is the maximum driving capability, ie. the maximum DC current that can be sourced/sunk by the digital pad in order to guarantee the correct digital output voltage levels VOH and VOL.

12/60 DocID031240 Rev 4 D. CAD MODEL OF DEMONSTRATIVE LOCKING MECHANISM

D CAD Model of Demonstrative Locking Mechanism

53 APPENDICES

54 E. PYTHON CODE FOR THE DESIGNED PKE SYSTEM - KEY

E Python Code for the Designed PKE System - Key

E.1 main.py

1 ””” 2 TRITA−ITM−EX 2020:48 3 Relay Attack Resistant Passive Keyless Entry 4 Date : 2020−05−31 5 Author: Abel Valko 6 TRITA: ITM−EX 2020:48 7 Course : MF133X − Bachelor’s Thesis in Mechanica Enginnering , Mechatronics 8 9 Main frame for high level logic of the PKE system. Trivial code, all functions in imported packages. 10 ””” 11 12 import bluetooth 13 import time 14 15 import b t c o n f i g 16 import bt 17 import b t r s s i 18 import acc 19 20 def main ( ) : 21 bt . s e t u p bluetooth() #Make sure that bluetoothctl service is running and power is on 22 i d l e = False 23 print ( ” Socket setup complete ” ) 24 sleep mod = acc.sleep mode control module ( ) 25 sleep mod . s t a r t a c c m o n i t o r ( ) 26 while True : 27 attack warning = False 28 bt module = bt.Bt module server ( ) #A l l o c a t e resources and initialize bt module 29 i f bt module.connect() : 30 bt module. start r s s i m o n i t o r t h r e a d ( ) #S t a r t r s s i monitor 31 while True : 32 #Do not print log if in idle 33 i f idle == True: 34 r e c e i v e d , e r r o r = bt module. listen(timeout=1, printing=False) 35 else : 36 r e c e i v e d , e r r o r = bt module. listen() 37 i f received == None: 38 i d l e = False 39 i f e r r o r <= 0 : 40 break 41 else : 42 time . s l e e p ( 0 . 1 ) 43

55 APPENDICES

44 e l i f r e c e i v e d == bytearray ( ” k e e p alive”, btconfig. ENCODING) : 45 l i f e s i g n = ” a l i v e ” 46 #Only respond to keep−alive if in rssi range 47 i f bt module . i n r a n g e : 48 i f bt module.send(lifesign , False): 49 i f idle == False: 50 i d l e = True 51 print ( ” Veh icle unlocked . Entering i d l e . Responding to keep−a l i v e periodically”) 52 continue 53 else : 54 i d l e = False 55 break 56 e l i f r e c e i v e d == bytearray ( ”Wake up!”, btconfig. ENCODING) : 57 #Only reply to wake−up if in rssi range 58 i f bt module . i n r a n g e : 59 print ( ”Key in range ” ) 60 i f sleep mod . s l e e p : 61 i f attack warning == False: 62 attack warning == True 63 print ( ”WARNING! ACCESS REQUESTED WHILE SLEEPING” ) 64 else : 65 attack warning = False 66 print ( ” Sending wake−up confirmation ...”) 67 wakeup confirm = ”confirm wakeup ” 68 i d l e = False 69 i f bt module.send(wakeup confirm ) : 70 continue 71 else : 72 break 73 e l i f received[0:9] == bytearray (”challenge”, btconfig. ENCODING) : 74 print (”Calculating c h a l l e n g e response ” ) 75 response=”response” 76 print ( ” Sending c h a l l e n g e response ” ) 77 i d l e = False 78 i f bt module.send(response): 79 continue 80 else : 81 break 82 else : 83 i d l e = False 84 print ( ” I n v a l i d message r e c e i v e d . I g n o r i n g and proceeding”) 85 86 i f name == ” m a i n ”: 87 main ( )

56 E. PYTHON CODE FOR THE DESIGNED PKE SYSTEM - KEY

E.2 bt.py

1 ””” 2 TRITA−ITM−EX 2020:48 3 Relay Attack Resistant Passive Keyless Entry 4 Date : 2020−05−31 5 Author: Abel Valko 6 TRITA: ITM−EX 2020:48 7 Course : MF133X − Bachelor’s Thesis in Mechanica Enginnering , Mechatronics 8 9 Main control module for bluetooth module. Implements connection , rssi thread init , cleanup, 10 sending and receiving messages, and rssi callback. PyBluez as BT API . RFCOMM s o c k e t s . 11 ””” 12 13 import os 14 import bluetooth 15 import time 16 import threading 17 18 import b t c o n f i g 19 import b t r s s i 20 21 22 class Bt module server : 23 ””” Class for controlling the bluetooth module, Key is Server, Car i s Cient 24 ””” 25 26 def i n i t ( s e l f ) : 27 self.sock = bluetooth.BluetoothSocket(bluetooth.RFCOMM) # allocate resource 28 self.sock.bind((””,0)) #bind any adapter and any port 29 s e l f . c l i e n t s o c k = None 30 s e l f . v e h i c l e address = None 31 s e l f . r s s i thread = None 32 s e l f . s t o p r s s i thread = False #flag to stop rssi thread upon disconnect or reset 33 s e l f . r s s i = None #rolling average rssi readout 34 s e l f . r s s i q u e u e = [ ] #recent rssi readouts for averaging 35 s e l f . i n range = False #in rssi range flag 36 37 def s t a r t r s s i m o n i t o r thread(self): 38 ”””Starts a thread for monitoring rssi value of vehicle a d d r e s s . 39 Thread is killed upon disconnect or error. 40 C a l l s r s s i callback to update rssi on thread 41 ””” 42 s e l f . s t o p r s s i thread = False

57 APPENDICES

43 s e l f . r s s i thread = threading.Thread( 44 t a r g e t=b t rssi .monitor r s s i , 45 args =(lambda : s e l f . s t o p r s s i t h r e a d , ) , 46 kwargs={ 47 ’addr’: self.vehicle address[0] , 48 ’ parent ’ : s e l f , 49 ’sleep’ : btconfig.RSSI SLEEP, 50 ’ debug ’ : False 51 } 52 ) 53 s e l f . r s s i thread .daemon = True #dameonize 54 s e l f . r s s i thread.start() 55 56 def r s s i callback(self , rssi): 57 ”””Passed RSSI readouts from thread and updates rssi value. 58 ””” 59 #Only average full queue 60 i f rssi == None: 61 s e l f . r s s i = None 62 s e l f . i n range = False 63 return 64 else : 65 #calculate and update rssi 66 i f len ( s e l f . r s s i q u e u e ) >= btconfig .RSSI AVERAGE LENGTH: 67 s e l f . r s s i queue.append(rssi) 68 s e l f . r s s i queue = self.rssi q u e u e [ 1 : ] 69 avg = 0 70 for i in s e l f . r s s i q u e u e : 71 avg += i 72 self.rssi=avg/btconfig.RSSI AVERAGE LENGTH 73 else : 74 s e l f . r s s i queue.append(rssi) 75 #update self.in range based on current rssi value 76 i f self.rssi == None: 77 s e l f . i n range = False 78 e l i f s e l f . r s s i >= btconfig .RSSI THRESHOLD [ 1 ] : 79 s e l f . i n r a n g e = True 80 e l i f s e l f . r s s i <= btconfig .RSSI THRESHOLD [ 0 ] : 81 s e l f . i n range = False 82 83 def c l o s e sockets(self): 84 #graceful exit 85 try : 86 s e l f . c l i e n t sock.close() 87 s e l f . sock . c l o s e ( ) 88 except bluetooth.BluetoothError as e: 89 print ( ” Error while c l o s i n g s o c k e t : ” ) 90 print ( e ) 91 s e l f . s t o p r s s i thread = True #make sure thread is stopped 92 i f s e l f . r s s i thread != None: 93 s e l f . r s s i thread.join() #wait for thread to die 94 95 def connect(self): 96 ”””Connects to self.vehicle address on socket

58 E. PYTHON CODE FOR THE DESIGNED PKE SYSTEM - KEY

97 ””” 98 print ( ” Waiting f o r connection ...”) 99 self.sock.listen(1) #Ready to accept 1 connection 100 self.sock.settimeout(btconfig.CONNECT TIMEOUT) #Socket timeout 101 c u r r e n t e r r o r = None 102 while True : #Ends only if connection is established . Key has no other job in the meantime. Could be threaded. 103 try : #Try to connect 104 s e l f . c l i e n t sock , self.vehicle address = self.sock. accept ( ) 105 break 106 except bluetooth.btcommon.BluetoothError as e: 107 #Errors excepted , connection retried 108 errno = e . args [ 0 ] 109 i f errno != current e r r o r : 110 print ( e ) 111 c u r r e n t error = errno 112 print ( ” Waiting f o r connection ...”) 113 print (”Connection established from ” + str (self.client s o c k . getpeername()) + ” at ” + str (self.vehicle address[0])) 114 115 #Only allow connection from the paired vehicle 116 i f self .vehicle address[0] != btconfig.CAR ADDR: 117 print ( ” Address does not match v e h i c l e . Blocking address ” ) 118 command = ” echo ’ block ’ ” + str (self.vehicle address[0]) + ”’\ nquit ’ | bluetoothctl” 119 os . system (command) #Block any unexpected devices that try to connect. Use Bluetoothctl. 120 time . s l e e p ( 0 . 1 ) #Sync 121 return False #Reloads socket and tries connection again 122 return True 123 124 def listen(self , timeout=btconfig .LISTEN TIMEOUT, printing=True) : 125 ”””Unfortunate legacy name... listening for message 126 ””” 127 p r i n t i n g = False 128 i f printing == True: 129 print (”Listening on c l i e n t socket ...”) 130 s e l f . c l i e n t sock .settimeout(timeout) 131 try : 132 data = s e l f . c l i e n t sock .recv(1024) 133 i f printing == True: 134 print (”Received: ” + str ( data ) ) 135 return data , 0 136 #timed out should be handled different to real errors 137 except bluetooth.BluetoothError as e: 138 i f e.args[0] == ”timed out ” : 139 return None , 1 140 print ( e ) 141 print ( ” F a i l e d . R e s e t t i n g s o c k e t and r e t u r n i n g to main frame ”) 142 s e l f . c l o s e s o c k e t s ( ) #cleanup 143 return None , −1

59 APPENDICES

144 145 def send(self , data, printing=True): 146 ”””Send message on socket””” 147 to send = bytearray (data , btconfig .ENCODING) 148 try : 149 s e l f . c l i e n t sock .send(to send ) 150 #Retry sending once, sync error may occur. Else cleanup and return 151 except bluetooth.BluetoothError as e: 152 i f printing == True: 153 print ( e ) 154 print ( ” Retrying to send . . . ” ) 155 try : 156 s e l f . c l i e n t sock .send(to send ) 157 except bluetooth.BluetoothError as e: 158 i f printing == True: 159 print ( e ) 160 print ( ” Sending f a i l e d . R e s e t t i n g s o c k e t and r e t u r n i n g to main frame ” ) 161 s e l f . c l o s e s o c k e t s ( ) 162 return False 163 i f printing == True: 164 print ( ” Message sent ” ) 165 return True 166 167 def s e t u p bluetooth(): 168 #Bluetoothctl setup, make sure everything is on and primed 169 print (”Resetting bluetoothctl”) 170 os . system ( ” sudo s y s t e m c t l stop bluetooth”) 171 os . system ( ” sudo s y s t e m c t l s t a r t bluetooth”) 172 os . system ( ” echo ’ power on\ nquit ’ | bluetoothctl”) 173 time . s l e e p ( 0 . 1 )

60 E. PYTHON CODE FOR THE DESIGNED PKE SYSTEM - KEY

E.3 bt_rssi.py

1 ””” 2 TRITA−ITM−EX 2020:48 3 Relay Attack Resistant Passive Keyless Entry 4 Date : 2020−05−31 5 Author: Abel Valko 6 TRITA: ITM−EX 2020:48 7 Course : MF133X − Bachelor’s Thesis in Mechanica Enginnering , Mechatronics 8 9 Main control module for bluetooth rssi module. Meant to be run in seperate thread, expects parent to 10 implement callback method. 11 ””” 12 13 import subprocess 14 import time 15 16 def m o n i t o r rssi(stop, addr, parent, sleep=1, debug=False): 17 ”””Scans for RSSI value of addr 18 Assumes already connected device , presumably hci0. Rfcomm. BT 4.0. h i c t o o l . 19 Parent must contain rssi callback method 20 ””” 21 hcitool cmd = [’sudo’, ’hcitool’, ’rssi’, str ( addr ) ] #h c i t o o l command to check rssi of device addr 22 r s s i i n t = 0 23 #Monitor runs until stop called from main thread 24 while True : 25 i f stop ( ) : #Called from main frame if connection abruptly ended 26 break 27 try : 28 rssi=subprocess.check output(hcitool cmd ) #Send command and get response 29 rssi=rssi.decode(’utf −8 ’ ) 30 r s s i i n t = None 31 #Parse for numerical value of rssi 32 for s in rssi.split(): 33 try : 34 r s s i i n t = int ( s ) 35 except ValueError : 36 pass 37 parent . r s s i callback(rssi i n t ) #Callback to parent for r s s i update 38 i f debug == True: 39 print (”RSSI: ” + str ( r s s i i n t ) ) 40 i f r s s i i n t == None : 41 i f debug == True: 42 print ( ”RSSI DEBUG1 : r s s i none ” ) 43 break 44 #Errors handled gracefully 45 except subprocess.CalledProcessError as e:

61 APPENDICES

46 r s s i i n t = None 47 parent . r s s i callback(rssi i n t ) 48 i f debug == True: 49 print ( ”RSSI DEBUG2 : r s s i e r r o r ” ) 50 break 51 time . s l e e p ( s l e e p )

62 E. PYTHON CODE FOR THE DESIGNED PKE SYSTEM - KEY

E.4 btconfig.py

1 ””” 2 TRITA−ITM−EX 2020:48 3 Relay Attack Resistant Passive Keyless Entry 4 Date : 2020−05−31 5 Author: Abel Valko 6 TRITA: ITM−EX 2020:48 7 Course : MF133X − Bachelor’s Thesis in Mechanica Enginnering , Mechatronics 8 9 Config parameters for bluetooth module. 10 ””” 11 12 CAR ADDR = ”B8:27:EB:99:F8:8A” #address of car 13 DEFAULT PORT = 1 #default port (legacy) 14 TIMEOUT = 10 #timeout for bluetooth.BluetoothSocket. recv ( ) 15 ENCODING = ” utf −8” #encoding f o r messages 16 RSSI THRESHOLD = ( −2 ,0) #hysteresis for rssi 17 DEBUG = True 18 RSSI SLEEP = 0.05 #rssi thread sleep time, due to hcitool interfacing this has little effect , the command takes too much time 19 RSSI AVERAGE LENGTH = 3 #RSSI queue length 20 CONNECT TIMEOUT = 1 #Default timeout for establishing connection 21 LISTEN TIMEOUT = 0 . 5 #Default timeout for recv

63 APPENDICES

E.5 acc.py

1 ””” 2 TRITA−ITM−EX 2020:48 3 Relay Attack Resistant Passive Keyless Entry 4 Date : 2020−05−31 5 Author: Abel Valko 6 TRITA: ITM−EX 2020:48 7 Course : MF133X − Bachelor’s Thesis in Mechanica Enginnering , Mechatronics 8 9 Main control module for accelerometer. Meant to run monitor in seperate thread 10 with callbacks to update sleep −mode parameters. 11 ””” 12 13 import smbus 14 import threading 15 import time 16 from math import s q r t 17 18 import a c c c o n f i g 19 20 class sleep mode control module : 21 def i n i t ( s e l f ) : 22 self.bus =smbus.SMBus(1) #init i2c bus 23 s e l f . s l e e p = False #Sleep mode, True if no motion detected for given time 24 s e l f . acc queue = [ ] #Queue of previous acc readouts 25 s e l f . a c c v a l u e = None #Current average acc value 26 s e l f . s l e e p t i m e r s t a r t = None #Start of most recent sleep timer 27 s e l f . s l e e p t i m e r active = False 28 s e l f . mpu init ( ) 29 30 def s t a r t a c c monitor(self): 31 #create thread and start it 32 thread=threading.Thread( 33 t a r g e t = monitor acc , 34 args = ( ) , 35 kwargs = { 36 ’ bus ’ : s e l f . bus , 37 ’ parent ’ : s e l f , 38 ’ s l e e p ’ : 0 . 1 , 39 ’ debug ’ : False 40 }) 41 thread . daemon = True 42 thread . s t a r t ( ) 43 44 def a c c callback(self , acc): 45 acc abs = sqrt((acc[0] −1) ∗∗2 + ( acc [1] −1) ∗∗2 + ( acc [2] −1) ∗∗2) # Get abs acceleration 46 s e l f . acc queue .append(acc abs )

64 E. PYTHON CODE FOR THE DESIGNED PKE SYSTEM - KEY

47 48 i f len ( s e l f . acc queue ) > accconfig .ACC QUEUE LEN: 49 s e l f . acc queue = self.acc queue [ 1 : ] 50 51 i f s e l f . a c c value != None: 52 #If acc too different from previous sleep false 53 i f abs ( ( s e l f . acc value −acc abs)/self .acc v a l u e ) > a c c c o n f i g .ACC TOLERANCE: 54 i f self.sleep == True: 55 print ( ” Sleep mode o f f ” ) 56 s e l f . s l e e p = False 57 s e l f . s l e e p t i m e r active = False 58 else : 59 #If sleep , continue sleeping 60 i f self.sleep: 61 pass 62 else : 63 #If not sleeping but sleep timer already on, check if timer done and sleep if so 64 i f s e l f . s l e e p t i m e r a c t i v e : 65 i f (time.time() − s e l f . s l e e p t i m e r s t a r t ) > accconfig .SLEEP TIMEOUT: 66 s e l f . s l e e p = True 67 print ( ” Sleep mode a c t i v e ” ) 68 #Else start timer 69 else : 70 s e l f . s l e e p t i m e r start = time.time() 71 s e l f . s l e e p t i m e r active = True 72 avg = 0 73 for value in s e l f . acc queue : 74 avg += value 75 s e l f . a c c value = avg/accconfig.ACC QUEUE LEN #will produce slow startup until queue is full , should just take a second or two 76 77 def mpu init(self): 78 #Vodoo magic for mpu init 79 s e l f . bus . w r i t e b y t e data(accconfig .DEVICE ADDRESS, a c c c o n f i g . SMPLRT DIV, 7) 80 s e l f . bus . w r i t e b y t e data(accconfig .DEVICE ADDRESS, a c c c o n f i g . PWR MGMT 1, 1) 81 s e l f . bus . w r i t e b y t e data(accconfig .DEVICE ADDRESS, a c c c o n f i g . CONFIG, 0) 82 s e l f . bus . w r i t e b y t e data(accconfig .DEVICE ADDRESS, a c c c o n f i g . GYRO CONFIG, 24) 83 s e l f . bus . w r i t e b y t e data(accconfig .DEVICE ADDRESS, a c c c o n f i g . INT ENABLE, 1) 84 85 def monitor acc(bus, parent , sleep=0.1, debug=False): 86 #call threaded, monitors accelerometer , expects parent with a c c callback method 87 while True : 88 acc x = read raw data(bus, accconfig .ACCEL XOUT H) /16384 89 acc y = read raw data(bus, accconfig .ACCEL YOUT H) /16384

65 APPENDICES

90 a c c z = read raw data(bus, accconfig .ACCEL ZOUT H) /16384 91 i f debug : 92 print (”Accelerometer readout : X =” , str ( acc x ) , ”Y =” , str ( acc y ) , ”Z = ”, str ( a c c z ) ) 93 parent . a c c callback((acc x , acc y , a c c z ) ) 94 time . s l e e p ( s l e e p ) 95 96 def read raw data(bus, addr): 97 #read data from addr on the i2c bus 98 high = bus . r e a d b y t e data(accconfig .DEVICE ADDRESS, addr ) 99 low = bus . r e a d b y t e data(accconfig .DEVICE ADDRESS, addr+1) 100 #combine readouts 101 value = ( ( high << 8) | low ) 102 #get negatives 103 i f value > 32768: 104 value = value − 65536 105 return value

66 E. PYTHON CODE FOR THE DESIGNED PKE SYSTEM - KEY

E.6 accconfig.py

1 ””” 2 TRITA−ITM−EX 2020:48 3 Relay Attack Resistant Passive Keyless Entry 4 Date : 2020−05−31 5 Author: Abel Valko 6 TRITA: ITM−EX 2020:48 7 Course : MF133X − Bachelor’s Thesis in Mechanica Enginnering , Mechatronics 8 9 Config parameters for accelerometer. 10 ””” 11 12 #I2C addresses, device address to sensor, acc module specific config 13 PWR MGMT 1 = 0x6B 14 SMPLRT DIV = 0x19 15 CONFIG = 0x1A 16 GYRO CONFIG = 0x1B 17 INT ENABLE = 0x38 18 ACCEL XOUT H = 0x3B 19 ACCEL YOUT H = 0x3D 20 ACCEL ZOUT H = 0x3F 21 GYRO XOUT H = 0x43 22 GYRO YOUT H = 0x45 23 GYRO ZOUT H = 0x47 24 25 DEVICE ADDRESS = 0x68 26 27 ACC QUEUE LEN = 10 28 ACC TOLERANCE = 0.05 29 SLEEP TIMEOUT = 10

67 APPENDICES

F Python Code for the Designed PKE System - Vehicle

F.1 main.py

1 ””” 2 TRITA−ITM−EX 2020:48 3 Relay Attack Resistant Passive Keyless Entry 4 Date : 2020−05−31 5 Author: Abel Valko 6 TRITA: ITM−EX 2020:48 7 Course : MF133X − Bachelor’s Thesis in Mechanica Enginnering , Mechatronics 8 9 Main frame for car software. 10 ””” 11 12 import fsm 13 import bt 14 15 def main ( ) : 16 bt . s e t u p bluetooth() 17 print ( ” S e t t i n g up v e h i c l e ” ) 18 vehicle = fsm.vehicle f s m ( ) 19 print ( ” Veh icle setup complete ” ) 20 v e h i c l e . run ( ) 21 22 i f name == ” m a i n ”: 23 main ( )

68 F. PYTHON CODE FOR THE DESIGNED PKE SYSTEM - VEHICLE

F.2 fsm.py

1 ””” 2 TRITA−ITM−EX 2020:48 3 Relay Attack Resistant Passive Keyless Entry 4 Date : 2020−05−31 5 Author: Abel Valko 6 TRITA: ITM−EX 2020:48 7 Course : MF133X − Bachelor’s Thesis in Mechanica Enginnering , Mechatronics 8 9 Implementation of finite state machine for door lock system. Architecture allows for added features. 10 ””” 11 12 import bt 13 import l o c k 14 15 #abstract class for vehicle states 16 class v e h i c l e : 17 def i n i t ( s e l f ) : 18 unlocked = None 19 #method for moving to next state, blocks until reqs for next state f u l f i l l e d 20 def transition(self , bt module ) : 21 pass 22 #method for entering state , basic setup 23 def enter(self): 24 pass 25 26 class v e h i c l e unlocked(vehicle): 27 def enter(self): 28 s e l f . unlocked = True 29 l o c k . unlock ( ) 30 print ( ” Veh icle unlocked ” ) 31 def transition(self , bt module ) : 32 print ( ” Waiting f o r l o c k i n g procedure . V e r i f y i n g key in range periodically.”) 33 bt . w a i t f o r l o c k i n g procedure(bt module ) 34 print ( ” Locking procedure complete ” ) 35 n e x t state = vehicle l o c k e d ( ) 36 return n e x t s t a t e , None 37 38 class v e h i c l e locked(vehicle): 39 def enter(self): 40 self.unlocked=False 41 l o c k . l o c k ( ) 42 print ( ” Veh icle locked ” ) 43 def transition(self , bt module=None) : 44 print ( ” Waiting f o r unlock authentication ...”) 45 #u n l o c k authentication blocks until authentication complete and then returns bt module with current socket fo com 46 bt module = bt.unlock authentication() 47 print (”Authenticaton complete ” )

69 APPENDICES

48 n e x t state = vehicle u n l o c k e d ( ) 49 return n e x t s t a t e , bt module 50 51 def v e h i c l e s e t u p ( ) : 52 s t a t e = v e h i c l e l o c k e d ( ) 53 return s t a t e 54 55 #finite state machine for vehicle 56 class v e h i c l e f s m : 57 def i n i t ( s e l f ) : 58 s e l f . s t a t e = v e h i c l e s e t u p ( ) 59 s e l f . bt module = bt.bt s o c k e t ( ) 60 61 def run ( s e l f ) : 62 while True : 63 n e x t state, self.bt module = self.state.transition(self. bt module ) 64 s e l f . s t a t e = n e x t s t a t e 65 s e l f . s t a t e . e n t e r ( )

70 F. PYTHON CODE FOR THE DESIGNED PKE SYSTEM - VEHICLE

F.3 bt.py

1 ””” 2 TRITA−ITM−EX 2020:48 3 Relay Attack Resistant Passive Keyless Entry 4 Date : 2020−05−31 5 Author: Abel Valko 6 TRITA: ITM−EX 2020:48 7 Course : MF133X − Bachelor’s Thesis in Mechanica Enginnering , Mechatronics 8 9 Main control module for bluetooth. Implements socekts , all authentication , wake−ups e t c . 10 ””” 11 12 import bluetooth 13 import b t c o n f i g 14 import time 15 import os 16 17 class b t s o c k e t : 18 def i n i t ( s e l f ) : 19 self.sock = bluetooth.BluetoothSocket(bluetooth.RFCOMM) 20 self.sock.setblocking(True) 21 def c l o s e socket(self): 22 try : 23 s e l f . sock . c l o s e ( ) 24 except bluetooth.BluetoothError as e: 25 print ( ” Error while c l o s i n g s o c k e t : ” ) 26 print ( e ) 27 28 def w a i t f o r l o c k i n g procedure(bt module ) : 29 #legacy method 30 v e r i f y k e y i n r a n g e ( bt module ) 31 32 def v e r i f y k e y i n r a n g e ( bt module ) : 33 to send = ” k e e p a l i v e ” 34 e x p e c t e d r e s p o n s e = bytearray (”alive” , btconfig .ENCODING) 35 bt module.sock.settimeout(0.2) 36 s t r i k e s = 0 37 while True : 38 i f s t r i k e s >= btconfig.KEEP ALIVE STRIKES : 39 bt module. close s o c k e t ( ) 40 print ( ”Keep−a l i v e f a l s e ” ) 41 return 42 try : 43 bt module.sock.send(to send ) 44 except bluetooth.BluetoothError as e: 45 try : 46 time . s l e e p ( 0 . 1 ) 47 bt module.sock.send(to send ) 48 except bluetooth.BluetoothError as e: 49 print ( e ) #not needed 50 print ( ”Keep−a l i v e f a l s e ” )

71 APPENDICES

51 bt module. close s o c k e t ( ) 52 return 53 try : 54 response = bt module.sock.recv(1024) 55 except bluetooth.BluetoothError as e: 56 i f e == ” timed out ” : 57 s t r i k e s += 1 58 continue 59 else : 60 print ( e ) 61 print ( ”Keep−a l i v e f a l s e ” ) 62 bt module. close s o c k e t ( ) 63 return 64 i f response == expected r e s p o n s e : 65 pass 66 else : 67 s t r i k e s += 1 68 continue 69 time . s l e e p ( 0 . 2 ) 70 71 def u n l o c k authentication(): 72 print ( ” Waiting f o r connection ...”) 73 while True : 74 bt module = establish connection() 75 i f get wakeup ( bt module) == True: 76 i f authenticate k e y ( bt module) == True: 77 return bt module 78 79 def authenticate k e y ( bt module ) : 80 challenge = ”challenge” 81 try : 82 bt module.sock.send(challenge) 83 except bluetooth.BluetoothError as e: 84 print ( e ) 85 print ( ” Retrying with new challenge”) 86 challenge =”challenge2” #not really implemented since no encryption is used 87 try : 88 bt module.sock.send(challenge) 89 except bluetooth.BluetoothError as e: 90 print ( e ) 91 print ( ” Sending o f c h a l l e n g e f a i l e d . R e s e t t i n g s o c k e t and authentication”) 92 bt module. close s o c k e t ( ) 93 return False 94 print (”Challenge sent ” ) 95 print (”Calculating expected response ” ) 96 e x p e c t e d r e s p o n s e = bytearray (”response” , btconfig .ENCODING) 97 bt module.sock.settimeout(0.1) 98 try : 99 print ( ” Awaiting response ” ) 100 response = bt module.sock.recv(1024) 101 except bluetooth.BluetoothError as e: 102 print ( e )

72 F. PYTHON CODE FOR THE DESIGNED PKE SYSTEM - VEHICLE

103 print (”Authentication f a i l e d . R e s e t t i n g s o c k e t and authentication”) 104 bt module. close s o c k e t ( ) 105 return False 106 i f response == expected r e s p o n s e : 107 print (”Challenge response confirmed”) 108 return True 109 else : 110 print (”Challenge f a i l e d . R e s e t t i n g s o c k e t and authentication”) 111 bt module. close s o c k e t ( ) 112 print ( ”Key placed on timeout to think about what i t has done . . ” ) 113 time . s l e e p (10) 114 return False 115 116 #implement actual protocol 117 def get wakeup ( bt module ) : 118 to send = ”Wake up ! ” 119 e x p e c t e d r e s p o n s e = bytearray ( ” confirm wakeup” , btconfig .ENCODING) 120 bt module.sock.settimeout(0.1) 121 #error handling, close socket if needed 122 while True : 123 try : 124 bt module.sock.send(to send ) 125 except bluetooth.BluetoothError as e: 126 print ( e ) 127 print ( ” r e t r y i n g to send wake−up” ) 128 try : 129 bt module.sock.send(to send ) 130 print ( ”Wake−up sent ” ) 131 except bluetooth.BluetoothError as e: 132 print ( e ) 133 print ( ” Sending o f wake−up f a i l e d . R e s e t t i n g s o c k e t and authentication”) 134 bt module. close s o c k e t ( ) 135 return False 136 #error handling 137 try : 138 response = bt module.sock.recv(1024) 139 except bluetooth.BluetoothError as e: 140 i f e.args[0] == ”timed out ” : 141 continue 142 else : 143 print ( e ) 144 print ( ”Wake−up not confirmed . R e s e t t i n g s o c k e t and authentication”) 145 bt module. close s o c k e t ( ) 146 return False 147 i f response == expected r e s p o n s e : 148 print ( ”Wake−up confirmed”) 149 return True 150 else : 151 print ( ”Wake−up response i n c o r r e c t . Expecting ” + e x p e c t e d r e s p o n s e + ” Received ” + response + ”.

73 APPENDICES

R e s e t t i n g s o c k e t and authentication”) 152 bt module. close s o c k e t ( ) 153 return False 154 155 def e s t a b l i s h connection(): 156 c u r r e n t e r r o r = None 157 print ( ” Trying to connect ...”) 158 while True : 159 bt module = b t s o c k e t ( ) 160 try : 161 bt module.sock.connect((btconfig .KEY ADDR, btconfig .PORT)) 162 print (”Connection with key established”) 163 return bt module 164 except bluetooth.btcommon.BluetoothError as e: 165 errno = e . args [ 0 ] 166 i f errno != current e r r o r : 167 i f errno == 112: 168 print ( str ( e ) + ” − Key i s out o f range or down” ) 169 e l i f errno == 111: 170 print ( str ( e ) + ” − Key de tect ed but i s not ready to r e c e i v e connection , program may not be s t a r t e d ”) 171 e l i f errno == 113: 172 print ( str ( e ) + ” − Bluetoothctl power may be o f f ” ) 173 print (”Attempting to turn on power ” ) 174 os . system ( ” echo ’ power on\ nquit ’ | bluetoothctl”) 175 e l i f errno == 7 7 : 176 print ( str ( e ) + ” − Unexpected s o c k e t f a i l i u r e , v e r i f y s e t t i n g s and socket −p r o t o c o l sync ” ) 177 else : 178 print ( e ) 179 c u r r e n t error = errno 180 print ( ” Trying to connect ...”) 181 pass 182 def s e t u p bluetooth(): 183 print (”Resetting bluetoothctl”) 184 os . system ( ” sudo s y s t e m c t l stop bluetooth”) 185 os . system ( ” sudo s y s t e m c t l s t a r t bluetooth”) 186 os . system ( ” echo ’ power on\ nquit ’ | bluetoothctl”) 187 time . s l e e p ( 0 . 1 )

74 F. PYTHON CODE FOR THE DESIGNED PKE SYSTEM - VEHICLE

F.4 btconfig.py

1 ””” 2 TRITA−ITM−EX 2020:48 3 Relay Attack Resistant Passive Keyless Entry 4 Date : 2020−05−31 5 Author: Abel Valko 6 TRITA: ITM−EX 2020:48 7 Course : MF133X − Bachelor’s Thesis in Mechanica Enginnering , Mechatronics 8 9 Config parameters for bluetooth. 10 ””” 11 12 KEY ADDR = ”B8:27:EB:35:4C:35” #address of key fob 13 PORT = 1 #default port 14 TIMEOUT = 10 #timeout for bluetooth.BluetoothSocket.recv() in s 15 ENCODING = ” utf −8” 16 KEEP ALIVE STRIKES = 3

75 APPENDICES

F.5 lock.py

1 ””” 2 TRITA−ITM−EX 2020:48 3 Relay Attack Resistant Passive Keyless Entry 4 Date : 2020−05−31 5 Author: Abel Valko 6 TRITA: ITM−EX 2020:48 7 Course : MF133X − Bachelor’s Thesis in Mechanica Enginnering , Mechatronics 8 9 Main control module for servo. Raspberry Pi Zero W 1.1 and SG90s. 10 ””” 11 12 import RPi .GPIO as GPIO 13 from time import s l e e p 14 15 #GPIO pin used 16 SERVO PWM PIN = 18 17 18 #i n i t 19 GPIO. setmode (GPIO.BCM) 20 GPIO. setup (SERVO PWM PIN, GPIO.OUT) 21 pwm = GPIO.PWM(SERVO PWM PIN, 50) 22 pwm. s t a r t ( 0 ) 23 24 def l o c k ( ) : 25 duty = 2 26 r o t a t e l o c k ( duty ) 27 print (”Locking”) 28 s l e e p ( 0 . 5 ) 29 30 def unlock ( ) : 31 duty = 13 32 print (”Unlocking”) 33 r o t a t e l o c k ( duty ) 34 s l e e p ( 0 . 5 ) 35 36 def r o t a t e lock(duty): 37 #send pwm signal to turn servo 38 GPIO. output (SERVO PWM PIN, True ) 39 pwm.ChangeDutyCycle(duty) 40 s l e e p ( 0 . 5 ) 41 GPIO. output (SERVO PWM PIN, False ) 42 pwm.ChangeDutyCycle(0) #bit of cleanup to avoid jitter

76 G. TEST CASES

G Test Cases

Test Case 1 KeyNotInRange

Actors: Key, Vehicle

Preconditions: Key outside of connection range. Vehicle locked.

Success Scenario:

1. The Key approaches the vehicle.

2. The Vehicle establishes connection with the Key.

3. The Key does not enter unlocking range (around 1 meter).

4. The Vehicle sends a wake-up to the Key.

5. The Key is not in range, it does not confirm the wake-up.

Postconditions: Vehicle still locked. (Connection established between Key and Vehicle.)

Test Case 2 SuccesfulUnlock

Actors: Key, Vehicle

Preconditions: Key outside of connection range. Vehicle locked. Key in sleep mode. Success Scenario:

1. The Key approaches the vehicle.

2. The Vehicle establishes connection with the Key.

3. The Key enters the unlocking range (around 1 meter).

4. The Vehicle unlocks. (wake-up and challenge completed)

Postconditions: Vehicle is unlocked.

77 APPENDICES

Test Case 3 SleepModeWhileInCar

Actors: Key, Vehicle

Preconditions: Key within unlocking range. Live connection between Vehicle and Key. Vehicle unlocked. Key not in sleep- mode. Success Scenario:

1. The Key sits still for given amount of time and enters sleep mode.

Postconditions: Vehicle remains unlocked. (Connection alive between Key and Vehicle.)

Test Case 4 SuccesfulLock

Actors: Key, Vehicle

Preconditions: Key within unlocking range. Live connection between Vehicle and Key. Vehicle unlocked. Key in sleep- mode. Success Scenario:

1. The Key leaves the unlocking range of the Vehicle but stays in connection range.

2. The Vehicle is locked.

Postconditions: Vehicle is locked. Key not in sleep-mode. (Connec- tion alive between Key and Vehicle.)

78 G. TEST CASES

Test Case 5 RelayAttack

Actors: Key, Vehicle, (Attacker)

Preconditions: Key outside of connection range. Vehicle locked. Key in sleep-mode. Success Scenario:

1. Attacker relays connection request from Vehicle to Key. (Simulated by bringing the Vehicle in range of the Key)

2. The Key connects.

3. Vehicle sends wake-up.

4. Key does not confirm wake-up. Key alerts user to potential attack.

Postconditions: Vehicle remains locked. Key remains in sleep mode. Key sends attack alert. (Connection alive between Key and Vehicle.)

79 TRITA ITM-EX 2020:48

www.kth.se