Relay Attack Resistant Passive Keyless Entry

See discussions, stats, and author profiles for this publication at: https://www.researchgate.
net/publication/351761565
Relay Attack Resistant Passive Keyless Entry: Securing PKE Systems with
Immobility Detection
Thesis · August 2020

DOI: 10.13140/RG.2.2.14835.45600
CITATIONS READS
2 2,891
1 author:
Abel Valko
KTH Royal Institute of Technology
2 PUBLICATIONS 2 CITATIONS
SEE PROFILE
All content following this page was uploaded by Abel Valko on 21 May 2021.
The user has requested enhancement of the downloaded file.

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 säkerhetsbrist av moderna fordon är deras

sårbarhet mot så kallade ’relay attacker’. Dessa typer av
attacker, där signaler mellan bilen och nyckeln vidarebe-
fordras, kringgår all kryptering och låser upp bilen utan att
ha direkt tillgång till nyckeln. En stor del av kommersiella
fordon tillämpar ’Passive Keyless Entry’ (PKE) som byg-
ger på ’challenge-response’ metoder som visats vara särkilt
utsatta för dessa attacker.
En mängd olika skyddssystem har föreslagits på se-
nare år, men många saknar erforderlig robusthet eller ge-
nomörbarhet. Ett lämpligt system bör uppfylla en rad olika
kriterier. Strategin måste grundas på en omgivningspara-
meter som är både oföränderlig och tillräckligt rymdbero-
ende att två nära positoner kan skiljas åt. Dessutom ska
systemet vara kostnadseffektivt, implementerbart, och ta
hänsyn till användarkomfort såsom batteritid.
Projektets huvudsyfte är konstruktionen och analysen
av ett ’relay attack’ resistent PKE system. I detta projekt
ingår också en analys av ett antal föreslagna försvar och ett
förslag om en ny metod: ’Approach Curve Matching’. Slut-
satsen dras att de mest lovande taktikerna är: analys av Jac-
card indexet av Wi-Fi hotspots, ’Distance Bounding Pro-
tocols’, ’Approach Curve Matching’ och ’Immobility Detec-
tion’ som också implementeras i prototyp PKE systemet.
Projektet utvecklar först ett PKE system med två Rasp-
berry Pis som agerar som bilens och nyckelns mikrodatorer
och implementerar kommunikationsprotokollet med hjälp
av Bluetooth. ’Immobility Detection’ är sedan implemen-
terad genom en inbyggd accelerometer i nyckeln. Slutligen
testas och utvärderas systemet. Det konkluderas att trots
att ’Immobility Detection’s effektivitet inte är helt omfat-
tande är den lätt att implementera, kostnadseffektiv, och
kan bidra till en betydlig ökning av säkerheten hos PKE
system. Vidare observerade projektet att Bluetooths ’Re-
ceived Signal Strength Indicator’ (RSSI) mätningar är ut-
satta för avsevärd ostadighet och är allmänt omgivningsbe-
roende. Därför anses Bluetooth RSSI inte lämplig för PKE
tillämpningar även om andra metoder för avstånsmätning
med Bluetooth kan ha högre prestanda. Det föreslås att
’Immobility Detection’ tillämpas av tillverkare omgående
medans andra potentiellt mer effektiva strategier utreds.
Keywords: Nyckellösa System, Åtkomstkontroll, Relay

Attack, IT-säkerhet, 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 Gülsever 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
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
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
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 Čapkun
[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 Čapkuns 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
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
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
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
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. Gülsever, “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. Čapkun, “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. Singelée and 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
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 , Galileo 1 E1B/C,
SBAS L1C/A: WAAS, EGNOS, MSAS, GAGAN
Operational limits 2 Dynamics ≤4g
Altitude 50,000 m
Velocity 500 m/s
Velocity accuracy 3
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 mode 4
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 mode 7 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-Fix 8 Cold start 26 s 29 s 30 s 34 s 45 s
Hot start 1s 1s 1s 1s 1s
Aided starts 9
2s 2s 2s 3s 7s
Sensitivity in Continuous Tracking & -167 dBm -166 dBm -166 dBm -160 dBm -159 dBm
mode 10 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

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 inband 14 0 dBm
RF Input power on RF_IN outband 15
+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

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

VCC 16 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

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 Acquisition 19
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.

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.

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-

KEY POINTS
energy consumption. This application note describes how to
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

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.
Firmware download 264.16 ms ~16.38 mA Depends on the SPI/SDIO clock

and firmware size.

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

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 5s ~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
UDP upstream traffic of 100 11 s ~6.5 mA Can depend on the Access

UDP upstream traffic of 100 10.5 s ~1.93 mA Can depend on the Access
Note: To optimize power consumption in DTIM modes, the frequency drift of LP_CLK should be within 1 second lower than +-100 ppm.

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)
and is capable of measuring accelerations with
Features 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
 Car key applications Tape and

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
0.38
Current consumption in @Vdd = 1.8 V(4)
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)
Current consumption @ Vdd = 1.8 V(4) 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
VOH Digital high-level output voltage IOH = 4 mA(5) VDD_IO - 0.2 V
VOL Digital low-level output voltage IOL = 4 mA(5) 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 2 0 2 0 : 4 8
3 Relay A t t a c k R e s i s t a n t P a s s i v e K e y l e s s Entry
4 Date : 2020−05−31
5 Author : Abel Valko
6 TRITA : ITM−EX 2 0 2 0 : 4 8
7 Course : MF133X − B a c h e l o r ’ s T h e s i s i n Mechanica Enginnering ,
Mechatronics
8
9 Main frame f o r h i g h l e v e l l o g i c o f t h e PKE s y s t e m . T r i v i a l code ,
a l l f u n c t i o n s in imported packages .
10 ”””
11
12 import b l u e t o o t h
13 import time
14
15 import btconfig
16 import bt
17 import bt rssi
18 import acc
19
20 def main ( ) :
21 bt . s e t u p b l u e t o o t h ( ) #Make s u r e
t h a t b l u e t o o t h c t l s e r v i c e i s r u n n i n g and power i s on
22 i d l e = False
23 print ( ” S o c k e t s e t u p c o m p l e t e ” )
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 . B t m o d u l e s e r v e r ( ) #A l l o c a t e
r e s o u r c e s and i n i t i a l i z e b t module
29 i f bt module . c o n n e c t ( ) :
30 bt module . s t a r t 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 n o t p r i n t l o g i f i n i d l e
33 i f i d l e == True :
34 r e c e i v e d , e r r o r = bt module . l i s t e n ( t i m e o u t =1 ,
p r i n t i n g=F a l s e )
35 else :
36 r e c e i v e d , e r r o r = bt module . l i s t e n ( )
37 i f r e c e i v e d == 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 a l i v e ” , b t c o n f i g .
ENCODING) :
45 lifesign = ” alive ”
46 #Only r e s p o n d t o keep−a l i v e i f i n r s s i r an g e
47 i f bt module . i n r a n g e :
48 i f bt module . send ( l i f e s i g n , F a l s e ) :
49 i f i d l e == F a l s e :
50 i d l e = True
51 print ( ” V e h i c l e u n l o c k e d . E n t e r i n g i d l e .
Responding t o 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 ! ” , b t c o n f i g .
ENCODING) :
57 #Only r e p l y t o wake−up i f i n r s s i r an g e
58 i f bt module . i n r a n g e :
59 print ( ”Key i n r a n g e ” )
60 i f sleep mod . s l e e p :
61 i f a t t a c k w a r n i n g == F a l s e :
62 a t t a c k w a r n i n g == True
63 print ( ”WARNING! ACCESS REQUESTED WHILE
SLEEPING” )
64 else :
65 attack warning = False
66 print ( ” Sending wake−up c o n f i r m a t i o n . . . ” )
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 r e c e i v e d [ 0 : 9 ] == bytearray ( ” c h a l l e n g e ” , b t c o n f i g .
ENCODING) :
74 print ( ” C a l c u l a t i n g c h a l l e n g e r e s p o n s e ” )
75 response = ” response ”
76 print ( ” Sending c h a l l e n g e r e s p o n s e ” )
77 i d l e = False
78 i f bt module . send ( r e s p o n s e ) :
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 if name == ” main ”:
87 main ( )
56
E.2 bt.py
1 ”””
2 TRITA−ITM−EX 2 0 2 0 : 4 8
4 Date : 2020−05−31
6 TRITA : ITM−EX 2 0 2 0 : 4 8
Mechatronics
8
9 Main c o n t r o l module f o r b l u e t o o t h module . Implements c o n n e c t i o n ,
r s s i thread i n i t , cleanup ,
10 s e n d i n g and r e c e i v i n g messages , and r s s i c a l l b a c k . 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 ””” C l a s s f o r c o n t r o l l i n g t h e b l u e t o o t h module , Key i s S e r v e r , Car
i s Cient
24 ”””
25
26 def init ( self ) :
27 s e l f . s o c k = b l u e t o o t h . B l u e t o o t h S o c k e t ( b l u e t o o t h .RFCOMM) #
a l l o c a t e resource
28 s e l f . s o c k . bind ( ( ” ” , 0 ) ) #b i n d any a d a p t e r 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 a d d r e s s = None
31 s e l f . r s s i t h r e a d = None
32 s e l f . s t o p r s s i t h r e a d = False #f l a g t o s t o p r s s i t h r e a d
upon d i s c o n n e c t or r e s e t
33 s e l f . r s s i = None #r o l l i n g a v e r a g e r s s i
readout
34 s e l f . rssi queue = [ ] #r e c e n t r s s i r e a d o u t s f o r
averaging
35 s e l f . in range = False #i n r s s i r a ng e f l a g
36
37 def s t a r t r s s i m o n i t o r t h r e a d ( s e l f ) :
38 ””” S t a r t s a t h r e a d f o r m o n i t o r i n g r s s i v a l u e o f v e h i c l e a d d r e s s
.
39 Thread i s k i l l e d upon d i s c o n n e c t or e r r o r .
40 C a l l s r s s i c a l l b a c k t o u p d a t e r s s i on t h r e a d
41 ”””
42 s e l f . s t o p r s s i t h r e a d = False
57
APPENDICES
43 s e l f . r s s i t h r e a d = t h r e a d i n g . Thread (
44 t a r g e t=b t r s s i . m o n i t o r r s s i ,
45 a r g s =(lambda : s e l f . s t o p r s s i t h r e a d , ) ,
46 kwargs={
47 ’ addr ’ : s e l f . v e h i c l e a d d r e s s [ 0 ] ,
48 ’ parent ’ : s e l f ,
49 ’ s l e e p ’ : b t c o n f i g . RSSI SLEEP ,
50 ’ debug ’ : F a l s e
51 }
52 )
53 s e l f . r s s i t h r e a d . daemon = True #dameonize
54 s e l f . rssi thread . start ()
55
56 def r s s i c a l l b a c k ( s e l f , r s s i ) :
57 ””” Passed RSSI r e a d o u t s from t h r e a d and u p d a t e s r s s i v a l u e .
58 ”””
59 #Only a v e r a g e f u l l queue
60 i f r s s i == None :
61 s e l f . r s s i = None
62 s e l f . in range = False
63 return
64 else :
65 #c a l c u l a t e and u p d a t e r s s i
66 i f len ( s e l f . r s s i q u e u e ) >= b t c o n f i g . RSSI AVERAGE LENGTH :
67 s e l f . r s s i q u e u e . append ( r s s i )
68 s el f . rssi queue = s e l f . rssi queue [ 1 : ]
69 avg = 0
70 f o r i in s e l f . r s s i q u e u e :
71 avg += i
72 s e l f . r s s i = avg / b t c o n f i g . RSSI AVERAGE LENGTH
73 else :
74 s e l f . r s s i q u e u e . append ( r s s i )
75 #u p d a t e s e l f . i n r a n g e b a s e d on c u r r e n t r s s i v a l u e
76 i f s e l f . r s s i == None :
78 e l i f s e l f . r s s i >= b t c o n f i g . 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 <= b t c o n f i g . RSSI THRESHOLD [ 0 ] :
82
83 def c l o s e s o c k e t s ( s e l f ) :
84 #g r a c e f u l e x i t
85 try :
86 s e l f . client sock . close ()
87 s e l f . sock . c l o s e ( )
88 except b l u e t o o t h . B l u e t o o t h E r r o r a s e :
89 print ( ” E r r o r w h i l e 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 t h r e a d = True #make s u r e t h r e a d i s s t o p p e d
92 i f s e l f . r s s i t h r e a d != None :
93 s e l f . rssi thread . join () #w a i t f o r t h r e a d t o d i e
94
95 def c o n n e c t ( s e l f ) :
96 ””” Connects t o s e l f . v e h i c l e a d d r e s s on s o c k e t
58
97 ”””
98 print ( ” Waiting f o r c o n n e c t i o n . . . ” )
99 s e l f . sock . l i s t e n (1) #Ready t o a c c e p t 1 c o n n e c t i o n
100 s e l f . s o c k . s e t t i m e o u t ( b t c o n f i g .CONNECT TIMEOUT) #S o c k e t t i m e o u t
101 c u r r e n t e r r o r = None
102 while True : #Ends o n l y i f c o n n e c t i o n i s e s t a b l i s h e d
. Key has no o t h e r j o b i n t h e meantime . Could be t h r e a d e d .
103 try : #Try t o c o n n e c t
104 s e l f . c l i e n t s o c k , s e l f . v e h i c l e a d d r e s s = s e l f . sock .
accept ()
105 break
106 except b l u e t o o t h . btcommon . B l u e t o o t h E r r o r a s e :
107 #E r r o r s e x c e p t e d , c o n n e c t i o n r e t r i e d
108 errno = e . args [ 0 ]
109 i f e r r n o != c u r r e n t e r r o r :
110 print ( e )
111 current error = errno
113 print ( ” Connection e s t a b l i s h e d from ” + s t r ( s e l f . c l i e n t s o c k .
getpeername ( ) ) + ” a t ” + s t r ( s e l f . v e h i c l e a d d r e s s [ 0 ] ) )
114
115 #Only a l l o w c o n n e c t i o n from t h e p a i r e d v e h i c l e
116 i f s e l f . v e h i c l e a d d r e s s [ 0 ] != b t c o n f i g .CAR ADDR:
117 print ( ” Address d o e s not match v e h i c l e . B l o c k i n g a d d r e s s ” )
118 command = ” echo ’ b l o c k ’ ” + s t r ( s e l f . v e h i c l e a d d r e s s [ 0 ] ) +
” ’\ nquit ’ | b l u e t o o t h c t l ”
119 o s . system ( command ) #B l o c k any u n e x p e c t e d d e v i c e s t h a t t r y
t o c o n n e c t . Use B l u e t o o t h c t l .
120 time . s l e e p ( 0 . 1 ) #Sync
121 return F a l s e #R e l o a d s s o c k e t and t r i e s c o n n e c t i o n
again
122 return True
123
124 def l i s t e n ( s e l f , t i m e o u t=b t c o n f i g . LISTEN TIMEOUT, p r i n t i n g=True ) :
125 ””” U n f o r t u n a t e l e g a c y name . . . l i s t e n i n g f o r message
126 ”””
127 printing = False
128 i f p r i n t i n g == True :
129 print ( ” L i s t e n i n g on c l i e n t s o c k e t . . . ” )
130 s e l f . c l i e n t s o c k . settimeout ( timeout )
131 try :
132 data = s e l f . c l i e n t s o c k . r e c v ( 1 0 2 4 )
134 print ( ” R e c e i v e d : ” + s t r ( data ) )
135 return data , 0
136 #timed o u t s h o u l d be h a n d l e d d i f f e r e n t t o r e a l e r r o r s
138 i f e . a r g s [ 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 t o main frame
”)
142 s e l f . close sockets () #c l e a n u p
143 return None , −1
59
APPENDICES
144
145 def send ( s e l f , data , p r i n t i n g=True ) :
146 ””” Send message on s o c k e t ”””
147 t o s e n d = bytearray ( data , b t c o n f i g .ENCODING)
148 try :
149 s e l f . c l i e n t s o c k . send ( t o s e n d )
150 #Retry s e n d i n g once , sync e r r o r may o c c u r . E l s e c l e a n u p and
return
153 print ( e )
154 print ( ” R e t r y i n g t o send . . . ” )
155 try :
156 s e l f . c l i e n t s o c k . send ( t o s e n d )
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 t o main frame ” )
161 s e l f . close sockets ()
162 return F a l s e
164 print ( ” Message s e n t ” )
165 return True
166
167 def s e t u p b l u e t o o t h ( ) :
168 #B l u e t o o t h c t l s e t u p , make s u r e e v e r y t h i n g i s on and primed
169 print ( ” R e s e t t i n g b l u e t o o t h c t l ” )
170 o s . system ( ” sudo s y s t e m c t l s t o p b l u e t o o t h ” )
171 o s . system ( ” sudo s y s t e m c t l s t a r t b l u e t o o t h ” )
172 o s . system ( ” echo ’ power on \ n q u i t ’ | b l u e t o o t h c t l ” )
173 time . s l e e p ( 0 . 1 )
60
E.3 bt_rssi.py
1 ”””
2 TRITA−ITM−EX 2 0 2 0 : 4 8
4 Date : 2020−05−31
6 TRITA : ITM−EX 2 0 2 0 : 4 8
Mechatronics
8
9 Main c o n t r o l module f o r b l u e t o o t h r s s i module . Meant t o be run i n
s ep er at e thread , e x p e c t s parent to
10 implement c a l l b a c k method .
11 ”””
12
13 import s u b p r o c e s s
14 import time
15
16 def m o n i t o r r s s i ( stop , addr , parent , s l e e p =1, debug=F a l s e ) :
17 ””” Scans f o r RSSI v a l u e o f addr
18 Assumes a l r e a d y c o n n e c t e d d e v i c e , p r e s u m a b l y h c i 0 . Rfcomm . BT 4 . 0 .
hictool .
19 Parent must c o n t a i n r s s i c a l l b a c k method
20 ”””
21 h c i t o o l c m d = [ ’ sudo ’ , ’ h c i t o o l ’ , ’ r s s i ’ , s t r ( addr ) ] #h c i t o o l
command t o c h e c k r s s i o f d e v i c e addr
22 rssi int = 0
23 #Monitor runs u n t i l s t o p c a l l e d from main t h r e a d
24 while True :
25 i f s t o p ( ) : #C a l l e d from main frame i f c o n n e c t i o n a b r u p t l y
ended
26 break
27 try :
28 r s s i = s u b p r o c e s s . c h e c k o u t p u t ( h c i t o o l c m d ) #Send command
and g e t r e s p o n s e
29 r s s i = r s s i . decode ( ’ u t f −8 ’ )
30 r s s i i n t = None
31 #Parse f o r n u m e r i c a l v a l u e o f r s s i
32 f o r s in r s s i . s p l i t ( ) :
33 try :
34 r s s i i n t = int ( s )
35 except V a l u e E r r o r :
36 pass
37 p a r e n t . r s s i c a l l b a c k ( r s s i i n t ) #C a l l b a c k t o p a r e n t f o r
r s s i update
38 i f debug == True :
39 print ( ” RSSI : ” + s t r ( r s s i i n t ) )
40 i f r s s i i n t == None :
42 print ( ”RSSI DEBUG1 : r s s i none ” )
43 break
44 #E r r o r s h a n d l e d g r a c e f u l l y
45 except s u b p r o c e s s . C a l l e d P r o c e s s E r r o r a s e :
61
APPENDICES
46 r s s i i n t = None
47 parent . r s s i c a l l b a c k ( r s s i i n t )
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.4 btconfig.py
1 ”””
2 TRITA−ITM−EX 2 0 2 0 : 4 8
4 Date : 2020−05−31
6 TRITA : ITM−EX 2 0 2 0 : 4 8
Mechatronics
8
9 C o n f i g p a r a m e t e r s f o r b l u e t o o t h module .
10 ”””
11
12 CAR ADDR = ”B8 : 2 7 : EB : 9 9 : F8 : 8A” #a d d r e s s o f c a r
13 DEFAULT PORT = 1 #d e f a u l t p o r t ( l e g a c y )
14 TIMEOUT = 10 #t i m e o u t f o r b l u e t o o t h . B l u e t o o t h S o c k e t .
recv ()
15 ENCODING = ” u t f −8” #e n c o d i n g f o r messages
16 RSSI THRESHOLD = ( −2 ,0) #h y s t e r e s i s f o r r s s i
17 DEBUG = True
18 RSSI SLEEP = 0 . 0 5 #r s s i t h r e a d s l e e p time , due t o h c i t o o l
i n t e r f a c i n g t h i s has l i t t l e e f f e c t , t h e command t a k e s t o o much
t ime
19 RSSI AVERAGE LENGTH = 3 #RSSI queue l e n g t h
20 CONNECT TIMEOUT = 1 #D e f a u l t t i m e o u t f o r e s t a b l i s h i n g
connection
21 LISTEN TIMEOUT = 0 . 5 #D e f a u l t t i m e o u t f o r r e c v
63
APPENDICES
E.5 acc.py
1 ”””
2 TRITA−ITM−EX 2 0 2 0 : 4 8
4 Date : 2020−05−31
6 TRITA : ITM−EX 2 0 2 0 : 4 8
Mechatronics
8
9 Main c o n t r o l module f o r a c c e l e r o m e t e r . Meant t o run monitor i n
seperate thread
10 w i t h c a l l b a c k s t o u p d a t e s l e e p −mode p a r a m e t e r s .
11 ”””
12
13 import smbus
14 import t h r e a d i n g
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 :
22 s e l f . bus =smbus . SMBus ( 1 ) #i n i t i 2 c b u s
23 s e l f . sleep = False #S l e e p mode , True i f no
motion d e t e c t e d f o r g i v e n time
24 s e l f . acc queue = [ ] #Queue o f p r e v i o u s acc
readouts
25 s e l f . a c c v a l u e = None #Current a v e r a g e acc v a l u e
26 s e l f . s l e e p t i m e r s t a r t = None #S t a r t o f most r e c e n t s l e e p
timer
27 s e l f . s l e e p t i m e r a c t i v e = False
28 s e l f . mpu init ()
29
30 def s t a r t a c c m o n i t o r ( s e l f ) :
31 #c r e a t e t h r e a d and s t a r t i t
32 t h r e a d = t h r e a d i n g . Thread (
33 ta r g e t = monitor acc ,
34 args = () ,
35 kwargs = {
36 ’ bus ’ : s e l f . bus ,
37 ’ parent ’ : s e l f ,
38 ’ sleep ’ : 0.1 ,
39 ’ debug ’ : F a l s e
40 })
41 t h r e a d . daemon = True
42 thread . s t a r t ()
43
44 def a c c c a l l b a c k ( s e l f , a c c ) :
45 a c c a b s = s q r t ( ( a c c [ 0 ] − 1 ) ∗∗2 + ( a c c [ 1 ] − 1 ) ∗∗2 + ( a c c [ 2 ] − 1 ) ∗ ∗ 2 ) #
Get a b s a c c e l e r a t i o n
46 s e l f . a c c q u e u e . append ( a c c a b s )
64
47
48 i f len ( s e l f . a c c q u e u e ) > a c c c o n f i g . ACC QUEUE LEN :
49 s e l f . acc queue = s e l f . acc queue [ 1 : ]
50
51 i f s e l f . a c c v a l u e != None :
52 #I f acc t o o d i f f e r e n t from p r e v i o u s s l e e p f a l s e
53 i f abs ( ( s e l f . a c c v a l u e −a c c a b s ) / s e l f . a c c v a l u e ) > a c c c o n f i g
.ACC TOLERANCE:
54 i f s e l f . s l e e p == True :
55 print ( ” S l e e p mode o f f ” )
56 s e l f . sleep = False
57 s e l f . s l e e p t i m e r a c t i v e = False
58 else :
59 #I f s l e e p , c o n t i n u e s l e e p i n g
60 if s e l f . sleep :
61 pass
62 else :
63 #I f n o t s l e e p i n g b u t s l e e p t i m e r a l r e a d y on , c h e c k
i f t i m e r done and s l e e p i f so
64 if self . sleep timer active :
65 i f ( time . time ( ) − s e l f . s l e e p t i m e r s t a r t ) >
a c c c o n f i g . SLEEP TIMEOUT :
66 s e l f . s l e e p = True
67 print ( ” S l e e p mode a c t i v e ” )
68 #E l s e s t a r t t i m e r
69 else :
70 s e l f . s l e e p t i m e r s t a r t = time . time ( )
71 s e l f . s l e e p t i m e r a c t i v e = True
72 avg = 0
73 f o r v a l u e in s e l f . a c c q u e u e :
74 avg += v a l u e
75 s e l f . a c c v a l u e = avg / a c c c o n f i g . ACC QUEUE LEN #w i l l p r o d u c e s l o w
s t a r t u p u n t i l queue i s f u l l , s h o u l d j u s t t a k e a s e c o n d or
two
76
77 def m p u i n i t ( s e l f ) :
78 #Vodoo magic f o r mpu i n i t
79 s e l f . bus . w r i t e b y t e d a t a ( a c c c o n f i g . DEVICE ADDRESS, a c c c o n f i g .
SMPLRT DIV, 7 )
PWR MGMT 1, 1 )
CONFIG, 0 )
GYRO CONFIG, 2 4 )
INT ENABLE, 1 )
84
85 def m o n i t o r a c c ( bus , parent , s l e e p =0.1 , debug=F a l s e ) :
86 #c a l l t h r e a d e d , m o n i t o r s a c c e l e r o m e t e r , e x p e c t s p a r e n t w i t h
a c c c a l l b a c k method
87 while True :
88 a c c x = r e a d r a w d a t a ( bus , a c c c o n f i g . ACCEL XOUT H) /16384
89 a c c y = r e a d r a w d a t a ( bus , a c c c o n f i g . ACCEL YOUT H) /16384
65
APPENDICES
90 a c c z = r e a d r a w d a t a ( bus , a c c c o n f i g . ACCEL ZOUT H) /16384

91 i f debug :
92 print ( ” A c c e l e r o m e t e r r e a d o u t : X =” , s t r ( a c c x ) , ”Y =” , s t r (
a c c y ) , ”Z = ” , s t r ( a c c z ) )
93 parent . a c c c a l l b a c k ( ( acc x , acc y , a c c z ) )
94 time . s l e e p ( s l e e p )
95
96 def r e a d r a w d a t a ( bus , addr ) :
97 #r e a d d a t a from addr on t h e i 2 c b u s
98 h i g h = bus . r e a d b y t e d a t a ( a c c c o n f i g . DEVICE ADDRESS, addr )
99 low = bus . r e a d b y t e d a t a ( a c c c o n f i g . DEVICE ADDRESS, addr +1)
100 #combine r e a d o u t s
101 v a l u e = ( ( h i g h << 8 ) | low )
102 #g e t n e g a t i v e s
103 i f value > 32768:
104 v a l u e = v a l u e − 65536
105 return v a l u e
66
E.6 accconfig.py
1 ”””
2 TRITA−ITM−EX 2 0 2 0 : 4 8
4 Date : 2020−05−31
6 TRITA : ITM−EX 2 0 2 0 : 4 8
Mechatronics
8
9 Config parameters f o r accelerometer .
10 ”””
11
12 #I2C a d d r e s s e s , d e v i c e a d d r e s s t o s e n s o r , acc module s p e c i f i c c o n f i g
13 PWR MGMT 1 = 0x6B
14 SMPLRT DIV = 0 x19
15 CONFIG = 0x1A
16 GYRO CONFIG = 0x1B
17 INT ENABLE = 0 x38
18 ACCEL XOUT H = 0x3B
19 ACCEL YOUT H = 0x3D
20 ACCEL ZOUT H = 0x3F
21 GYRO XOUT H = 0 x43
22 GYRO YOUT H = 0 x45
23 GYRO ZOUT H = 0 x47
24
25 DEVICE ADDRESS = 0 x68
26
27 ACC QUEUE LEN = 10
28 ACC TOLERANCE = 0 . 0 5
29 SLEEP TIMEOUT = 10
67
APPENDICES
F Python Code for the Designed PKE System - Vehicle

F.1 main.py
1 ”””
2 TRITA−ITM−EX 2 0 2 0 : 4 8
4 Date : 2020−05−31
6 TRITA : ITM−EX 2 0 2 0 : 4 8
Mechatronics
8
9 Main frame f o r c a r s o f t w a r e .
10 ”””
11
12 import fsm
13 import bt
14
15 def main ( ) :
16 bt . s e t u p b l u e t o o t h ( )
17 print ( ” S e t t i n g up v e h i c l e ” )
18 v e h i c l e = fsm . v e h i c l e f s m ( )
19 print ( ” V e h i c l e s e t u p c o m p l e t e ” )
20 v e h i c l e . run ( )
21
22 if name == ” main ”:
23 main ( )
68
F. PYTHON CODE FOR THE DESIGNED PKE SYSTEM - VEHICLE
F.2 fsm.py
1 ”””
2 TRITA−ITM−EX 2 0 2 0 : 4 8
4 Date : 2020−05−31
6 TRITA : ITM−EX 2 0 2 0 : 4 8
Mechatronics
8
9 I m p l e m e n t a t i o n o f f i n i t e s t a t e machine f o r door l o c k s y s t e m .
A r c h i t e c t u r e a l l o w s f o r added f e a t u r e s .
10 ”””
11
12 import bt
13 import l o c k
14
15 #a b s t r a c t c l a s s f o r v e h i c l e s t a t e s
16 c l a s s v e h i c l e :
18 u n l o c k e d = None
19 #method f o r moving t o n e x t s t a t e , b l o c k s u n t i l r e q s f o r n e x t s t a t e
fulfilled
20 def t r a n s i t i o n ( s e l f , bt module ) :
21 pass
22 #method f o r e n t e r i n g s t a t e , b a s i c s e t u p
23 def e n t e r ( s e l f ) :
24 pass
25
26 c l a s s v e h i c l e u n l o c k e d ( v e h i c l e ) :
28 s e l f . u n l o c k e d = True
29 lock . unlock ( )
30 print ( ” V e h i c l e u n l o c k e d ” )
31 def t r a n s i t i o n ( s e l f , bt module ) :
32 print ( ” Waiting f o r l o c k i n g p r o c e d u r e . V e r i f y i n g key i n r a n g e
periodically . ”)
33 bt . w a i t f o r l o c k i n g p r o c e d u r e ( bt module )
34 print ( ” Locking p r o c e d u r e c o m p l e t e ” )
35 next state = vehicle locked ()
36 return n e x t s t a t e , None
37
38 c l a s s v e h i c l e l o c k e d ( v e h i c l e ) :
40 s e l f . unlocked = False
41 lock . lock ()
42 print ( ” V e h i c l e l o c k e d ” )
43 def t r a n s i t i o n ( s e l f , bt module=None ) :
44 print ( ” Waiting f o r u n l o c k a u t h e n t i c a t i o n . . . ” )
45 #u n l o c k a u t h e n t i c a t i o n b l o c k s u n t i l a u t h e n t i c a t i o n c o m p l e t e and
t h e n r e t u r n s b t m o d u l e w i t h c u r r e n t s o c k e t f o com
46 bt module = bt . u n l o c k a u t h e n t i c a t i o n ( )
47 print ( ” A u t h e n t i c a t o n c o m p l e t e ” )
69
APPENDICES
48 next state = vehicle unlocked ()

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 state = vehicle locked ()
53 return s t a t e
54
55 #f i n i t e s t a t e machine f o r v e h i c l e
56 c l a s s v e h i c l e f s m :
58 s e l f . state = vehicle setup ()
59 s e l f . bt module = bt . b t s o c k e t ( )
60
61 def run ( s e l f ) :
62 while True :
63 n e x t s t a t e , s e l f . bt module = s e l f . s t a t e . t r a n s i t i o n ( s e l f .
bt module )
64 s e l f . state = next state
65 s e l f . state . enter ()
70
F.3 bt.py
1 ”””
2 TRITA−ITM−EX 2 0 2 0 : 4 8
4 Date : 2020−05−31
6 TRITA : ITM−EX 2 0 2 0 : 4 8
Mechatronics
8
9 Main c o n t r o l module f o r b l u e t o o t h . Implements s o c e k t s , a l l
a u t h e n t i c a t i o n , wake−ups e t c .
10 ”””
11
12 import bluetooth
13 import btconfig
14 import time
15 import os
16
17 class bt socket :
19 s e l f . s o c k = b l u e t o o t h . B l u e t o o t h S o c k e t ( b l u e t o o t h .RFCOMM)
20 s e l f . s o c k . s e t b l o c k i n g ( True )
21 def c l o s e s o c k e t ( s e l f ) :
22 try :
23 s e l f . sock . c l o s e ( )
25 print ( ” E r r o r w h i l e 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 p r o c e d u r e ( bt module ) :
29 #l e g a c y 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 = ” keep alive ”
34 e x p e c t e d r e s p o n s e = bytearray ( ” a l i v e ” , b t c o n f i g .ENCODING)
35 bt module . s o c k . s e t t i m e o u t ( 0 . 2 )
36 strikes = 0
37 while True :
38 i f s t r i k e s >= b t c o n f i g . KEEP ALIVE STRIKES :
39 bt module . c l o s e 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 . s o c k . send ( t o s e n d )
45 try :
46 time . s l e e p ( 0 . 1 )
49 print ( e ) #n o t needed
71
APPENDICES
52 return
53 try :
54 r e s p o n s e = bt module . s o c k . r e c v ( 1 0 2 4 )
56 i f e == ” timed out ” :
57 s t r i k e s += 1
58 continue
59 else :
60 print ( e )
63 return
64 i f r e s p o n s e == e x p e c t e d 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 a u t h e n t i c a t i o n ( ) :
73 while True :
74 bt module = e s t a b l i s h c o n n e c t i o n ( )
75 i f get wakeup ( bt module ) == True :
76 i f a u t h e n t i c a t e k e y ( bt module ) == True :
77 return bt module
78
79 def a u t h e n t i c a t e k e y ( bt module ) :
80 challenge = ” challenge ”
81 try :
82 bt module . s o c k . send ( c h a l l e n g e )
84 print ( e )
85 print ( ” R e t r y i n g with new c h a l l e n g e ” )
86 c h a l l e n g e = ” c h a l l e n g e 2 ” #n o t r e a l l y implemented s i n c e no
e n c r y p t i o n i s used
87 try :
88 bt module . s o c k . send ( c h a l l e n g 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 ”)
93 return F a l s e
94 print ( ” C h a l l e n g e s e n t ” )
95 print ( ” C a l c u l a t i n g e x p e c t e d r e s p o n s e ” )
96 e x p e c t e d r e s p o n s e = bytearray ( ” r e s p o n s e ” , b t c o n f i g .ENCODING)
98 try :
99 print ( ” Awaiting r e s p o n s e ” )
102 print ( e )
72
103 print ( ” A u t h e n t i c a t i o n f a i l e d . R e s e t t i n g s o c k e t and

authentication ”)
107 print ( ” C h a l l e n g e r e s p o n s e c o n f i r m e d ” )
108 return True
109 else :
110 print ( ” 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 a u t h e n t i c a t i o n ” )
112 print ( ”Key p l a c e d on t i m e o u t t o t h i n k about what i t has done . . ”
)
113 time . s l e e p ( 1 0 )
115
116 #implement a c t u a l p r o t o c o l
117 def get wakeup ( bt module ) :
118 t o s e n d = ”Wake up ! ”
119 e x p e c t e d r e s p o n s e = bytearray ( ” confirm wakeup ” , b t c o n f i g .ENCODING)
121 #e r r o r h a n d l i n g , c l o s e s o c k e t i f needed
122 while True :
123 try :
126 print ( e )
127 print ( ” r e t r y i n g t o send wake−up” )
128 try :
130 print ( ”Wake−up s e n t ” )
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 ”)
136 #e r r o r h a n d l i n g
137 try :
140 i f e . a r g s [ 0 ] == ” timed out ” :
141 continue
142 else :
143 print ( e )
144 print ( ”Wake−up not c o n f i r m e d . R e s e t t i n g s o c k e t and
authentication ”)
148 print ( ”Wake−up c o n f i r m e d ” )
149 return True
150 else :
151 print ( ”Wake−up r e s p o n s e i n c o r r e c t . E x p e c t i n g ” +
expected response + ” Received ” + response + ” .
73
APPENDICES
R e s e t t i n g s o c k e t and a u t h e n t i c a t i o n ” )
154
155 def e s t a b l i s h c o n n e c t i o n ( ) :
156 c u r r e n t e r r o r = None
157 print ( ” Trying t o c o n n e c t . . . ” )
158 while True :
159 bt module = b t s o c k e t ( )
160 try :
161 bt module . s o c k . c o n n e c t ( ( b t c o n f i g .KEY ADDR, b t c o n f i g .PORT) )
162 print ( ” Connection with key e s t a b l i s h e d ” )
163 return bt module
164 except b l u e t o o t h . btcommon . B l u e t o o t h E r r o r a s e :
165 errno = e . args [ 0 ]
166 i f e r r n o != c u r r e n t e r r o r :
167 i f e r r n o == 1 1 2 :
168 print ( s t r ( e ) + ” − Key i s out o f r a n g e o r down” )
169 e l i f e r r n o == 1 1 1 :
170 print ( s t r ( e ) + ” − Key d e t e c t e d but i s not ready t o
r e c e i v e c o n n e c t i o n , program may not be s t a r t e d
”)
171 e l i f e r r n o == 1 1 3 :
172 print ( s t r ( e ) + ” − B l u e t o o t h c t l power may be o f f ” )
173 print ( ” Attempting t o t u r n on power ” )
175 e l i f e r r n o == 7 7 :
176 print ( s t r ( 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 s o c k e t −p r o t o c o l sync ” )
177 else :
178 print ( e )
179 current error = errno
180 print ( ” Trying t o c o n n e c t . . . ” )
181 pass
182 def s e t u p b l u e t o o t h ( ) :
183 print ( ” R e s e t t i n g b l u e t o o t h c t l ” )
184 o s . system ( ” sudo s y s t e m c t l s t o p b l u e t o o t h ” )
185 o s . system ( ” sudo s y s t e m c t l s t a r t b l u e t o o t h ” )
187 time . s l e e p ( 0 . 1 )
74
F.4 btconfig.py
1 ”””
2 TRITA−ITM−EX 2 0 2 0 : 4 8
4 Date : 2020−05−31
6 TRITA : ITM−EX 2 0 2 0 : 4 8
Mechatronics
8
9 Config parameters f o r b l u e t o o t h .
10 ”””
11
12 KEY ADDR = ”B8 : 2 7 : EB: 3 5 : 4C: 3 5 ” #a d d r e s s o f k e y f o b
13 PORT = 1 #d e f a u l t p o r t
14 TIMEOUT = 10 #t i m e o u t f o r b l u e t o o t h . B l u e t o o t h S o c k e t . r e c v ( ) i n s
15 ENCODING = ” u t f −8”
16 KEEP ALIVE STRIKES = 3
75
APPENDICES
F.5 lock.py
1 ”””
2 TRITA−ITM−EX 2 0 2 0 : 4 8
4 Date : 2020−05−31
6 TRITA : ITM−EX 2 0 2 0 : 4 8
Mechatronics
8
9 Main c o n t r o l module f o r s e r v o . R a s p b e r r y Pi Zero W 1 . 1 and SG90s .
10 ”””
11
12 import RPi . GPIO a s GPIO
13 from time import s l e e p
14
15 #GPIO p i n used
16 SERVO PWM PIN = 18
17
18 #i n i t
19 GPIO . setmode (GPIO .BCM)
20 GPIO . s e t u p (SERVO PWM PIN, GPIO .OUT)
21 pwm = GPIO .PWM(SERVO PWM PIN, 5 0 )
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 sleep (0.5)
29
30 def u n l o c k ( ) :
31 duty = 13
32 print ( ” U n l o c k i n g ” )
33 r o t a t e l o c k ( duty )
34 sleep (0.5)
35
36 def r o t a t e l o c k ( duty ) :
37 #send pwm s i g n a l t o t u r n s e r v o
38 GPIO . output (SERVO PWM PIN, True )
39 pwm. ChangeDutyCycle ( duty )
40 sleep (0.5)
41 GPIO . output (SERVO PWM PIN, F a l s e )
42 pwm. ChangeDutyCycle ( 0 ) #b i t o f c l e a n u p t o a v o i d j i t t e r
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
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
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
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
View publication stats

Relay Attack Resistant Passive Keyless Entry

Uploaded by

Copyright:

Available Formats

Relay Attack Resistant Passive Keyless Entry

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Relay Attack Resistant Passive Keyless Entry

Uploaded by

Copyright:

Available Formats

See discussions, stats, and author profiles for this publication at: https://www.researchgate.

Thesis · August 2020

The user has requested enhancement of the downloaded file.

Relay Attack Resistant

KTH ROYAL INSTITUTE OF TECHNOLOGY

Bachelor’s Thesis at ITM

Keywords: Passive Keyless Entry, Relay Attack, Mafia

En betydande säkerhetsbrist av moderna fordon är deras

Keywords: Nyckellösa System, Åtkomstkontroll, Relay

2.1 Protocol diagram of typical PKE system. . . . . . . . . . . . . . . . . . 6

4.1 Connection diagram for the MPU6050 accelerometer to Raspberry Pi Zero. 22

BLE Bluetooth Low Energy

DTW Dynamic Time Warping

GPIO General Purpose Input/Output

PKE Passive Keyless Entry

SARA Signal Amplification Relay Attack

UHF Ultra High Frequency

• How effective is Immobility Detection as a method of protection against relay

• How does Immobility Detection compare to other potential methods of protec-

• Is Bluetooth Low Energy (BLE) a viable alternative to Radio-Frequency Iden-

feasibility and subsequently compared to the solution presented and developed in

2.1 Passive Keyless Entry

1. The car periodically broadcasts a wake-up message on a Low Frequency (LF)

The same process as described above is presented in Figure 2.1. A variation on

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

2.2 Relay Attack

As mentioned previously, while the LF RFID needed to establish connection

2.3 Key Fob Design

2.3.2 Wireless Technology

3.1 Received Signal Strength Indicator

3.2 Coordinate Tracing

3.4 Jaccard Similarity of Wi-Fi Access Points

3.5 Distance Bounding

3.6 Immobility Detection

3.7 Approach Curve Matching

4.1.2 Bluetooth Module

Figure 4.1: Connection diagram for the MPU6050 accelerometer to Raspberry Pi

4.1.4 Locking and Servo Motor

4.2.2 Authentication Protocol

3. The key then assesses the accelerometer readouts and determines if it is in

Figure 4.3: Sequence diagram of a successful unlocking sequence. (Figure made

4.2.3 Software Architecture

Evaluation of Immobility Detection This project has designed and developed

Additional Security Features There are a variety of added precautionary fea-

This thesis investigated, implemented, and assessed an Immobility Detection en-

[1] Statistics Sweden. (2020, Jan) Registered vehicles January 2006–December

[2] ——, “Preliminary population statistics 2019,” https://www.scb.se/

[5] A. I. Alrabady and S. M. Mahmud, “Analysis of attacks against the security of

[6] M. Gülsever, “A Study on Vulnerabilities in Connected Cars,” B.Sc. Thesis,

[7] J. Wang, K. Lounis, and M. Zulkernine, “CSKES: A Context-Based Se-

[8] A. Francillon, B. Danev, and S. Capkun, “Relay Attacks on Passive Keyless

[9] W. Choi, M. Seo, and D. Hoon Lee, “Sound-Proximity: 2-Factor

[10] K. Leuven. (2018, Sep) Fast, Furious and Insecure: Passive

[15] ——. Lexus 2018 NX300H Owner’s Manual (OM78212U). [Online].

[16] J. Rodriguez. (2016, Oct) Long-range RFID emitter an-

[29] M. J. Hussain, L. Lu, and H. Zhu, “TIGHT: A Cross-Layer RF Distance

[30] K. B. Rasmussen. (2010, Aug) Realisation of RF Distance Bounding. [Online].

[31] Ford Motor Company. Motion Sensing Key Fob. [Online].