Relay Attack Resistant Passive Keyless Entry
Relay Attack Resistant Passive Keyless Entry
Relay Attack Resistant Passive Keyless Entry
net/publication/351761565
Relay Attack Resistant Passive Keyless Entry: Securing PKE Systems with
Immobility Detection
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.
ABEL VALKO
ABEL VALKO
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.
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
LF Low Frequency
RF Radio Frequency
RFID Radio-Frequency Identification
RKS Remote Keyless System
RSSI Received Signal Strength Indicator
Introduction
In Sweden alone there are near five million registered, in use, personal vehicles
[1]. Approximately one vehicle for every two individuals [2]. The rapidly increasing
connectivity of these vehicles and the shift from mechanical to electronic and wireless
systems gives rise to new security vulnerabilities. Modern methods of car theft are
a prime example of newly digitalized exploits owing to the spread of digital lock
systems. The Remote Keyless System (RKS) has all but replaced the previous
mechanical lock mechanism in cars with its Passive Keyless Entry (PKE) variant
becoming standard in most high-end brands instead of its active counterpart. The
traditional active RKS is a unidirectional system where the user unlocks the vehicle
with a remote control, a.k.a. ’key fob’. The PKE System, explained in detail in
Section 2.1, unlocks the car automatically as the user approaches the vehicle with
the key fob - without the need for any interaction with the user interface. It employs
bidirectional communication where the car sends a wake-up signal to the key when
it is within range (commonly under 1 meter) and the driver takes hold of the handle,
proceeded by a challenge response from the key which, if correct, will unlock the
vehicle. A similar check may be performed in order to start the vehicle [3, 4].
This system increases user comfort due to the eliminated interaction and with
the encryption algorithm and challenge-response technique that is employed in most
recent implementations, explained in Section 2.1, assures high resistance to many
methods of attacks. However, it is not secure against relay attacks - also known
as Mafia Fraud - and Signal Amplification Relay Attack (SARA) which are attacks
that do not require decryption and are not affected by the encryption algorithm’s
complexity, nor can they be eliminated using alternative protocols [4, 5]. A review
by Gü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:
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
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. 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)
6
2.1. PASSIVE KEYLESS ENTRY
For this, two RFID zones are required, as depicted in Figure 2.2, with one
reaching outside of the car (generally in a range no more then one meter from the
doors) for unlocking and one exclusively on the inside of the vehicle for starting the
engine. Note that while the LF zones are strictly in a few meter radius around the
car the range of the UHF transmitter can be significantly larger [3, 4, 7, 8].
2.1.2 Encryption
While this paper does not focus on the encryption algorithms used in PKE systems
it is briefly summarized as follows: Both the vehicle and the key fob share a secret
hardware key unique to a manufactured vehicle. When the key fob has acknowledged
that it is in range the car generates a pseudo-random code to be transmitted as the
challenge. The key receives the challenge and uses it to generate a response using a
cipher such as KeeLoq or DST [8]. During this time the car will also generate the
response and compare it to the received response from the key. In theory, this is
a one-way operation which can neither be predicted, reverse engineered, or brute-
forced. While the cryptography method used in PKE can itself be attacked [10],
this goes beyond the scope of this paper; which assumes that the encryption method
can be fully relied upon.
7
CHAPTER 2. BACKGROUND
2.2.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)
8
2.2. RELAY ATTACK
Figure 2.4: Protocol diagram of relay attack on PKE System. (Figure made with
draw.io)
In cases where the range of the UHF RFID is not sufficient, or where a vehicle
with PKES is to be started and driven away, two agents are commonly needed. This
is analogous to a SARA but relays bidirectionally. Figure 2.4 illustrates a modified
version of Figure 2.1 illustrating this attack. Note that the effectiveness of relay
attacks are not diminished by increased cryptographic complexity as no cracking of
the cipher is needed.
2.2.2 Limitations
While relay attacks are very effective against current PKES Systems they do possess
inherent limitations which can be exploited when attempting to safeguard against
it. While relay attacks benefit from not having to interpret the signal or having to
crack the underlying encryption this also means that information can be sent safely,
which is crucial to several context-based protection mechanisms as discussed in
Chapter 3. Relay attacks also add delay to the sequence, exploited in for example
distance bounding methods. In addition, the relay devices require to be within
range of both the door and the key. Lastly, while the attacker can trick the car into
9
CHAPTER 2. BACKGROUND
believing that it is the key, the key fob itself can not actually be manipulated. Its
position, environmental characteristics, sent message, etc. are not affected by the
attack; a fact that can be utilized to design an effective defence.
2.2.3 Threat
Given the above, what threat do relay attacks actually pose? While conclusive
statistics on the occurrence of relay attacks are very difficult to find, these at-
tacks have been demonstrated in countless studies, reported on in news outlets, and
caught on security footage [11, 12]. While specific implementations vary even within
a single manufacturer’s different car models, decreasing the effectiveness of a single
setup, it has been found that vulnerability in modern vehicles is widespread with
many, if not all, vehicles with PKE being susceptible [8]. Furthermore, while hard-
ware availability and price was previously a mitigating factor, a Chinese security
research team succeeded in demonstrating a relay attack on a PKE System from a
maximum of 320 meters using 20 Euro equipment in 2017 [3, 13].
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.
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.
15
CHAPTER 3. PROPOSED DEFENSES
The main appeal of using Wi-Fi hotspots for relative localisation is also a large
drawback, namely the universality of the technology. While Wi-Fi hotspots exist
almost everywhere in populated areas, it is also a technology that can be cheaply and
easily spoofed. An attacker could, with readily available equipment, merely create
a few high strength hotspots beside both the key and vehicle thereby drowning out
’real’ hotspots. Such tampering could potentially be detected and defended against,
for example by filtering suddenly appearing hotspots or hotspots with suspicious
RSSI fluctuations. This, however, adds a great level of complexity to the solution,
increasing power consumption, lowering effectivity and time efficiency, as well as
greatly increasing development costs and time.
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.
17
CHAPTER 3. PROPOSED DEFENSES
not fabricated by an attacker, we can clearly distinguish if the key approached the
vehicle or not. A significant advantage of this method over Immobility Detection
is being able to protect against relay attacks while the key is in motion, such as
thefts in malls, outside stores, or in restaurants. In order for an attacker to bypass
such a defence, they would need to ensure that the RSSI received by the key varies
similarly in time as of that received by the car - a task potentially impossible owing
to the strong effect environmental factors have on RSSI.
This method can have multiple variations. The signal strength data could be
one-dimensional, measuring only the distance to a single receiver in the vehicle, or
multidimensional. However, measuring signal strength while entering the vehicle
may not provide a distinct enough fingerprint, or enough time for measurement. In
this case it is possible to employ this defense only for keyless engine start, by allowing
the data collection to proceed until the user enters the car. The characteristic signal
pattern of a key approaching the car, opening the door, entering the vehicle, etc.,
especially if multiple receivers are present in the car, would likely be complex enough
to thwart any relay attack. Any attempt to oversaturate the signal by an attacker
could also be detected, for example by comparing the approach curve to expected
user motion. Moreover, a machine learning algorithm could be trained to identify
approach curves that do not match common user patterns.
Due to exact sampling time disparity and variations in the absolute value of the
signal strength, Dynamic Time Warping (DTW) may be a suitable method for curve
matching. However, due to the processor intensive nature of such an algorithm the
data set from the key would likely need to be transferred to the vehicle’s on-board
computer for analysis. This also implies that - since the authenticity of the data set
must be ensured - the data set must be transmitted encrypted. While the encryption
and extra transmission has an effect on the battery life, the intensive computations
are on the vehicle side where more processing and battery power is available. By
using no new components (only the existing wireless chip is used) the overhead
power usage is not increased. The large number of extra transmissions needed to
guarantee a robust dataset to base the curve matching on does draw battery power,
but even older and somewhat outdated Bluetooth [34] and RSSI [35] chips rate their
Tx currents around 10 mA resulting in a significant but not prohibiting increase in
power usage. The exact power consumption must be further investigated in order
to determine the viability of Approach Curve Matching conclusively.
There are however multiple other challenges with Approach Curve Matching.
The algorithm relies on the symmetry of wave propagation, ie., that the signal will
theoretically be effected the same way by environmental factors between the key
and vehicle in both directions, but this may not be so in practice. Furthermore,
shifts in discrete sampling may have a compounding negative effect on asymmetry.
Due to this method employing a relatively complex algorithm, a large amount of
calibration and testing would be required before a viable commercial product could
be designed. The exact sampling rate, acceptance threshold, exact comparison
algorithm, etc. would also have to be determined through lengthy testing and
prototyping. The implementation of such a system into existing PKE systems is
18
3.7. APPROACH CURVE MATCHING
not as trivial as Immobility Detection. Therefore, while this thesis highlights the
viability and encourages further study of this method it does not investigate it in
depth.
19
Chapter 4
Implementation
The following chapter presents the implementation of the PKE system. It details
and motivates chosen hardware, software architecture, software logic and, finally,
presents the results obtained.
4.1 Hardware
The following sections describe the hardware setup for the implementation of an
Immobility Detection enhanced PKE system. While the exact setup is not identical
to most commercial systems, it is equivalent in all aspects that could affect the
defense systems effectiveness and implementability. Decisions regarding hardware
selection were based primarily on suitability for the project, economic viability, and
ease of use.
4.1.1 Microcomputer
The microcomputer used was the Raspberry Pi Zero W: a low-cost single-board
computer with inbuilt wireless (Wi-Fi and Bluetooth) capabilities. The computa-
tional power required for the authentication protocol and Bluetooth communication
is very low with essentially only the encryption being a processor heavy operation.
The actual chips used commercially in key fobs and on-board computers are natu-
rally highly optimised for cost and performance but the Raspberry Pi is suitable for
a proof of concept due to its ease of use. Furthermore it has an abundance of General
Purpose Input/Output (GPIO) pins which make it preferable for prototyping.
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.
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.
22
4.2. SOFTWARE
the locked/unlocked state of the vehicle. The servo control is achieved through
Pulse Width Modulation (PWM) on the Raspberry Pi’s GPIO pins. A duty cycle
of 2% at 50Hz is used for setting the servo at 0°and 13% for rotating to 180°. A
proposed CAD model can be seen in Appendix D. The models for the servo and
horn were sourced online, while the rest of the mechanism was designed in Solid
Edge [36, 37].
4.2 Software
The following sections describe the software setup for the implementation of an
Immobility Detection enhanced PKE system. The implementation was done in
three releases. One for the base functionality consisting of the software needed for
a PKE system without Immobility Detection, one with implemented Immobility
Detection, and finally implementing the demonstational locking mechanism. While
certain features were omitted or greatly simplified, such as the encryption algorithm
or excluding the initial button press before authentication begins often included in
commercial systems, care was taken in order to ensure that the general software
architecture and authentication protocol allowed for the implementation of such
features. These include support for multiple keys and active RKS. The source code
was written in Python and can be found in Appendices E and F.
Figure 4.2: Activity diagram of the unlocking process for the improved PKE system
with Immobility Detection. (Figure made with draw.io)
23
CHAPTER 4. IMPLEMENTATION
4.2.1 Logic
The logic underlying the PKE system is based on existing commercial systems to
a large degree. The Immobility Detection is a defence system easily implemented
distinct from the base functionality which is, with the exception of some omitted
features, identical to those described in Section 2.1. Figure 4.2 depicts an activity
diagram for unlocking the vehicle. The addition of Immobility Detection inserts
an extra control after checking for proximity of the vehicle - using RSSI - where
depending on the accelerometer readout either the authentication proceeds or the
user is alerted to a potential attack. The alert can take any form, in this project it
was sufficient to use a command-line message, but commercial systems would likely
use an audible alert from the key fob.
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.
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
25
CHAPTER 4. IMPLEMENTATION
modules. The Bluetooth module implemented all necessary functions for commu-
nication such as: establishing connection, cleaning up Bluetooth sockets, and send-
ing/receiving messages. The sleep-mode module similarly implemented all necessary
functionality for monitoring the accelerometer and determining sleep-mode.
The software of the vehicle’s on-board computer is much simpler. It is a two
state machine with a series of events as transition criteria from one state to the
other (the authentication protocol). The functions for the protocol are trivial, see
Figure 4.3 and Appendix F.
4.2.4 Encryption
For the purposes of this project no secure encryption algorithm was implemented.
As encryption does not influence the Immobility Detection system and the under-
lying logic it was deemed unnecessary. However, due to the protocol implementing
a mock challenge-response, an unencrypted and non-random placeholder for a po-
tential real challenge-response, the addition of such a feature would not alter the
architecture of the software as a whole. Similarly, other desired features can easily
be added to the system due to its modularity and regard for compatibility with
omitted features.
4.3 Results
After developing the software and constructing the setup, as seen in Figure 4.4, the
effectiveness of the implemented PKE system was assessed using a set of test cases
for common use cases, found in Appendix G.
Figure 4.4: Prototype setup of the implemented PKE system with the key fob and
accelerometer (left) and on-board computer and lock (right).
26
4.3. RESULTS
These include: the key entering communication range without getting close
enough to unlock the vehicle; a complete unlocking procedure; complete locking
procedure; the key entering sleep mode while in the vehicle; and a relay attack
on the car while the key is in sleep-mode. A summary of the testing is displayed
in Table 4.1. All tests were performed successfully, with the system behaving as
desired. It can be concluded that the PKE system worked as expected. While
due to RSSI inaccuracies inherent with Bluetooth the effective range was variable,
the system’s response time was, from an end user perspective, immediate. The
Immobility Detection system successfully protected against relay attacks while not
impeding the function of the base PKE system. The effectiveness of the implemented
defense is discussed further in Chapter 5.
Table 4.1: Table summarising acceptance testing for Immobility Detection enhanced
PKE
Test Pass/
Name Description Expected Outcome
ID Fail
Key entering connection
KeyNotIn- Connection established,
1 range but not unlock Pass
Range car locked
range
Succesful- Key from rest to unlock-
2 Vehicle unlocked Pass
Unlock ing car
SleepMode- Key enters sleep while
3 Car remains unlocked Pass
WhileInCar in unlocked car
Key from sleep-mode in
Succesful-
4 unlocked car to locked Car locked Pass
Lock
car
Relay attack while key Car remains locked, key
5 RelayAttack Pass
far from car in sleep alerts
However, the execution of the project also revealed insights crucial to this the-
sis. It was determined that existing PKE systems without any advanced form of
protection against relay attacks can benefit from Immobility Detection. Developing
such a defense system can be done to some extent separate from the existing one,
allowing for smooth integration while maintaining a low level of complexity, see
Section 4.2. Since the core functionality of the PKE system does not necessarily
need to be altered to accommodate Immobility Detection, as opposed to for example
distance bounding which requires an overhaul of the hardware as well as the proto-
col, the development and integration is relatively trivial. The hardware adjustment
required is minimal - the currently employed processor and RFID transmitter may
be kept - needing essentially only the addition of an accelerometer. Accelerometers
27
CHAPTER 4. IMPLEMENTATION
for similar applications are already on the market, as described in Chapter 3, and
are cost efficient. Furthermore, the addition of such a system was deemed to be
insignificant or even positive - depending on exact implementation - on battery life,
an important aspect in commercial applications.
The level of effectiveness of Bluetooth in the place of RFID based communication
did not have a notable affect on this project. However, some interesting trends
could be observed. The project used RSSI for measuring proximity to the vehicle,
a critical feature for both security and user comfort. There were, however, major
flaws detected with this. RSSI in general is not intended for absolute distance
measurements. While for the purposes of this project the test environment could
be limited for accurate calibration of the RSSI range, environmental factors in
a commercial application would affect the readout significantly. This effect was
observed to be so strong that the system designed - in its current form - could not
function effectively in a varying environment. Objects in the path of the key fob,
surrounding metallic objects, any covering material such as clothes, a bag, or even
a person’s hand all have a significant impact on the RSSI value. While Bluetooth,
or rather BLE, as a technology for PKE systems may yet be ideal, see Section 2.3.2,
this project observed that using RSSI is not viable.
28
Chapter 5
Discussion
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.
30
Chapter 6
Conclusion
31
Bibliography
[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.
33
BIBLIOGRAPHY
[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].
[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. Č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 RČ Distance-Bounding Protocol,” in 2012 IEEE International Confer-
ence on RFID-Technologies and Applications (RFID-TA), Nov 2012. doi:
https://doi.org/10.1109/RFID-TA.2012.6404571 pp. 74–79.
[27] D. Singelé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
[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].
[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
Appendices
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
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
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.
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
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].
⚠ 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
☞ 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.
16
Max 50 mVpp ripple
☞ 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
For more information about power requirements, see the ZOE-M8B System Integration Manual [1].
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.
☞ 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.
☞ 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.
45
AN1219: Power Consumption
Measurement Setup and Results on
WF(M)200
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.
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
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.
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.
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
This pin should be kept high when in Shutdown mode to achieve the lowest current consumption.
2. Measurement Summary
Static use cases for current consumption are mentioned in the table below.
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:
RX burst 41.8 mA
Listen 45.4 mA
Wi-Fi Power save DTIM1 1.02 s ~927 μA Can depend on the Access
Point and Wi-Fi context.
Wi-Fi Power save DTIM3 2.45 s ~327 μA Can depend on the Access
Point and Wi-Fi context.
Wi-Fi Power save DTIM10 4.1 s ~115 μA Can depend on the Access
Point and Wi-Fi context.
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
kbps in DTIM3 with burst profile Point and Wi-Fi context. It de-
use case 2 pends also on the burst profile.
UDP upstream traffic of 100 10.5 s ~1.93 mA Can depend on the Access
kbps in DTIM3 with burst profile Point and Wi-Fi context. It de-
use case 2 pends also on the burst profile.
Note: To optimize power consumption in DTIM modes, the frequency drift of LP_CLK should be within 1 second lower than +-100 ppm.
50
AIS2DW12
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
53
APPENDICES
54
E. PYTHON CODE FOR THE DESIGNED PKE SYSTEM - KEY
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. PYTHON CODE FOR THE DESIGNED PKE SYSTEM - KEY
E.2 bt.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 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 :
77 s e l f . in range = False
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 ] :
81 s e l f . in range = False
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
E. PYTHON CODE FOR THE DESIGNED PKE SYSTEM - KEY
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
112 print ( ” Waiting f o r c o n n e c t i o n . . . ” )
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 )
133 i f p r i n t i n g == True :
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
137 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 :
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
151 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 :
152 i f p r i n t i n g == True :
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 )
157 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 :
158 i f p r i n t i n g == True :
159 print ( e )
160 print ( ” Sending f a i l e d . R e s e t t i n g s o c k e t and
r e t u r n i n g t o main frame ” )
161 s e l f . close sockets ()
162 return F a l s e
163 i f p r i n t i n g == True :
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. PYTHON CODE FOR THE DESIGNED PKE SYSTEM - KEY
E.3 bt_rssi.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 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 :
41 i f debug == True :
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 )
48 i f debug == True :
49 print ( ”RSSI DEBUG2 : r s s i e r r o r ” )
50 break
51 time . s l e e p ( s l e e p )
62
E. PYTHON CODE FOR THE DESIGNED PKE SYSTEM - KEY
E.4 btconfig.py
1 ”””
2 TRITA−ITM−EX 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 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
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 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 :
21 def init ( self ) :
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
E. PYTHON CODE FOR THE DESIGNED PKE SYSTEM - KEY
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 )
80 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 .
PWR MGMT 1, 1 )
81 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 .
CONFIG, 0 )
82 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 .
GYRO CONFIG, 2 4 )
83 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 .
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
66
E. PYTHON CODE FOR THE DESIGNED PKE SYSTEM - KEY
E.6 accconfig.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 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
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 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
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 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 :
17 def init ( self ) :
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 ) :
27 def e n t e r ( s e l f ) :
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 ) :
39 def e n t e r ( s e l f ) :
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
70
F. PYTHON CODE FOR THE DESIGNED PKE SYSTEM - VEHICLE
F.3 bt.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 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 :
18 def init ( self ) :
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 ( )
24 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 :
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 )
44 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 :
45 try :
46 time . s l e e p ( 0 . 1 )
47 bt module . s o c k . send ( t o s e n d )
48 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 :
49 print ( e ) #n o t needed
50 print ( ”Keep−a l i v e f a l s e ” )
71
APPENDICES
51 bt module . c l o s e s o c k e t ( )
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 )
55 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 :
56 i f e == ” timed out ” :
57 s t r i k e s += 1
58 continue
59 else :
60 print ( e )
61 print ( ”Keep−a l i v e f a l s e ” )
62 bt module . c l o s e s o c k e t ( )
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 ( ) :
72 print ( ” Waiting f o r c o n n e c 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 )
83 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 :
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 )
89 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 :
90 print ( e )
91 print ( ” Sending o f c h a l l e n g e f a i l e d . R e s e t t i n g s o c k e t and
authentication ”)
92 bt module . c l o s e s o c k e t ( )
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)
97 bt module . s o c k . s e t t i m e o u t ( 0 . 1 )
98 try :
99 print ( ” Awaiting r e s p o n s e ” )
100 r e s p o n s e = bt module . s o c k . r e c v ( 1 0 2 4 )
101 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 :
102 print ( e )
72
F. PYTHON CODE FOR THE DESIGNED PKE SYSTEM - VEHICLE
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 ” )
152 bt module . c l o s e s o c k e t ( )
153 return F a l s e
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 ” )
174 o s . system ( ” echo ’ power on \ n q u i t ’ | b l u e t o o t h c t l ” )
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 ” )
186 o s . system ( ” echo ’ power on \ n q u i t ’ | b l u e t o o t h c t l ” )
187 time . s l e e p ( 0 . 1 )
74
F. PYTHON CODE FOR THE DESIGNED PKE SYSTEM - VEHICLE
F.4 btconfig.py
1 ”””
2 TRITA−ITM−EX 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 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
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 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
Success Scenario:
77
APPENDICES
1. The Key sits still for given amount of time and enters sleep mode.
1. The Key leaves the unlocking range of the Vehicle but stays in connection
range.
78
G. TEST CASES
4. Key does not confirm wake-up. Key alerts user to potential attack.
79
TRITA ITM-EX 2020:48
www.kth.se