Professional Documents
Culture Documents
Full Text 01
Full Text 01
Full Text 01
GRUNDNIVÅ, 15 HP
STOCKHOLM, SVERIGE 2018
MASAR ALMOSAWI
KTH
SKOLAN FÖR ELEKTROTEKNIK OCH DATAVETENSKAP
2
Abstract
This thesis describes the development of an IOT application based upon Digitiz-
ing a smart door lock for making it connected to the internet and able to recognize
employees that work in the office.
This thesis concentrates primarily on the security aspects by listing the typical
security challenges in IOT systems in general and summing these challenges up to
develop a functional and secure product from scratch. A microcontroller is chosen for
this project and a test environment is built to experiment and develop the security
breaches. Architectural designs are chosen for the API being developed and even for
the Android Application. A detailed description is made of the multi-master database
represented by Azure active directory and its importance to achieving the security of
an essential security breach. A new technique called Eddystone is introduced in the
project to serve the transmission protocol with Bluetooth beacons.
The final stage of this project is completing the development of the Android appli-
cation and making sure that all the subsystems developed do communicate with each
other, to deliver a functional and secure flow of the IoT system.
3
4
Sammanfattning
Följande examensarbete beskriver utvecklingen av en IoT-produkt baserad på dig-
italisering av ett smart dörrlås där applikationen ansluts till internet för igenkänning
av anställda som arbetar på ett kontor. Examensarbetet fokuserar primärt på säk-
erhetsaspekterna genom att notera de typiska säkerhetsutmaningarna som generella
IOT-system utsätts för och summerar dessa utmaningar för att utveckla en funktionell
och säker produkt från start av projektet.
En mikrokontroller väljs ut specifikt för projektet och en testmiljö byggs för att
undersöka och motverka eventuella säkerhetsbrister.
Rapporten ger även detaljerad beskrivning av multi-master databasen Azure Ac-
tive Directory och dess betydelse för att uppnå önskad säkerheten i systemet. En
ny teknik som heter Eddystone introduceras i projektet för att betjäna som över-
föringsprotokoll till Bluetooth-beacons.
Det sista steget i detta projekt kompletteras utvecklingen av systemet med Android-
applikation som ser till att alla utvecklade delsystem kommunicerar med varandra och
levererar ett funktionellt och säkert flöde av IOT-systemet.
5
6
Contents
1 Introduction 13
1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2 Problem Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.3 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.4 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.5 Research Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.6 Delimitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.7 Structure of Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2 Background 15
2.1 Internet of Things . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.1 IoT Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.2 Foundation Of physical environment in IoT . . . . . . . . . . . . . . 15
2.1.3 Basic Structure of Typical IoT Application . . . . . . . . . . . . . . 16
2.2 Consumer Internet Of Things . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3 Understanding IoT Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4 Security Challenges In IoT Systems . . . . . . . . . . . . . . . . . . . . . . . 17
2.4.1 LAN Mistrust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4.2 Environment Mistrust . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4.3 Application over-privilege . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4.4 No/Weak Authentication . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4.5 Implementation Flaws . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5 Security Solution For IoT Systems . . . . . . . . . . . . . . . . . . . . . . . 18
2.5.1 LAN Mistrust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5.2 Environment Mistrust . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5.3 Application Over-Privilege . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5.4 No/ Weak Authentication . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5.5 Implementation Flaws . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.6 The Smart Door Lock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.6.1 Direct Internet Connection . . . . . . . . . . . . . . . . . . . . . . . 20
2.6.2 Automatic Door Unlocking . . . . . . . . . . . . . . . . . . . . . . . 20
2.6.3 Other products on the market . . . . . . . . . . . . . . . . . . . . . . 21
2.7 Hardware Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.7.1 Microcontroller Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.7.2 Bluetooth Transmitter (Beacons) . . . . . . . . . . . . . . . . . . . . 22
2.7.3 Smartphone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.8 The Software Representation . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.9 Computing Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.9.1 Cloud Computing Models . . . . . . . . . . . . . . . . . . . . . . . . 22
3 Methodology 25
3.1 Pilot Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2 Design Of Prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3 Implementation of the Design . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4 Test Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
7
4 Setting Up A Test environment 27
4.1 Choice of Microcontroller Unit . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2 Choice of Bluetooth Beacons . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3 Test Environment/Experimental Design . . . . . . . . . . . . . . . . . . . . 27
4.3.1 Controlling a Door Circuit using a Relay . . . . . . . . . . . . . . . . 27
4.3.2 Test of MCU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3.3 Schematic of the electronic door lock . . . . . . . . . . . . . . . . . . 28
5 System Structure 29
5.1 Using Beacons to Monitor User Location . . . . . . . . . . . . . . . . . . . . 30
5.1.1 What is Eddystone? . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.2 What is REST API? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.3 Communicating to and from the REST API . . . . . . . . . . . . . . . . . . 31
5.4 What Is an Active directory . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.4.1 Using Azure Active Directory to Authenticate Users . . . . . . . . . 31
5.4.2 What is an Access Token and why do we need it? . . . . . . . . . . . 31
6 Software Development 33
6.1 Android Test Application to connect Google Beacon and Particle Device . . 33
6.1.1 Receiving A String from Beacon to App . . . . . . . . . . . . . . . . 33
6.1.2 Sending A Request from App to Particle . . . . . . . . . . . . . . . . 34
6.1.3 Particle Console IDE . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.2 Creating a Azure AD tenant and Developing Authentication API . . . . . . 35
6.2.1 Creating A Suitable Test Environment for WebAPI . . . . . . . . . . 36
6.2.2 Creating A Tenant And Users in Azure AD . . . . . . . . . . . . . . 36
6.2.3 Authentication API Development . . . . . . . . . . . . . . . . . . . . 37
6.2.4 Test: Retrieve a token . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.3 Door API Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.3.1 Security of API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.3.2 Connecting to Particle . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.3.3 Test: HTTP/S from Postman . . . . . . . . . . . . . . . . . . . . . . 40
6.4 Android Development/Architecture . . . . . . . . . . . . . . . . . . . . . . . 40
6.4.1 Using Android framework Components in SDL Application . . . . . 41
6.4.2 Application Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.4.3 Integration of Google Beacons . . . . . . . . . . . . . . . . . . . . . . 42
6.4.4 Permissions and requirements . . . . . . . . . . . . . . . . . . . . . . 43
8
List of Figures
1 Infrastructure of Iot ecosystem . . . . . . . . . . . . . . . . . . . . . . . . . 16
2 Naive architecture of the Smart Door Lock . . . . . . . . . . . . . . . . . . . 20
3 Example of house layout where a Bluetooth direction sense algorithm fails
to detect whether the user is inside the building or not. . . . . . . . . . . . . 21
4 Schematic of the working relay. The lock is represented as a LED in the
experimental design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5 System Architecture with a base flow of the system and security leakages. . 29
6 Communication between android app and Google API:s . . . . . . . . . . . 34
7 Basic flow for sending request from Android to particle . . . . . . . . . . . . 35
8 Retrieving an access token using HTTP request in form of JSON . . . . . . 38
9 HTTPS request and response from Particle Device . . . . . . . . . . . . . . 39
10 Android Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
11 Android App interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
12 Message Exchange Using Google Nearby . . . . . . . . . . . . . . . . . . . 43
13 Current test members of the Active Directory . . . . . . . . . . . . . . . . . 45
14 Request traffic to Google APIs, where Nearby API is blue and Proximity
API is green. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
15 The API’s request- and error rate. . . . . . . . . . . . . . . . . . . . . . . . 45
16 User login UI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
17 Login Successful UI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
18 Particle Spark Console displaying various events relative to the specific Pho-
ton Device. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
9
10
Acronyms
IoT Internet of Things
DGC Device-Gateway-Cloud
DIC Direct-Internet-Connection
IT Information Technology
OS Operating System
I/O Input/Output
11
SHA-1 Secure Hash Algorithm 1
UI User Interface
RSA Rivest–Shamir–Adleman
12
1 Introduction
This thesis examines and introduce a technology for a smart door based on the concepts
of internet of things (IoT).
1.1 Background
With the rapid advancement of the IoT market, companies tend to focus on the time-to-
market and releasing product as fast as possible instead of developing a secure substantial
product. This leaves many IoT product with inadequate protection against various forms of
malicious attacks. IoT security is an ever growing problem and even if there is a significant
amount of research on the topic there is not much substantial work about implementations
or standardizations that could solve this problem.
IoT security is of utmost importance as the aftermath of security breaches in IoT can
be devastating. A breach in a smart car or smart door lock could lead to stolen products
or even casualties in some extreme cases. Even if an undetected breach is not exploited
but still existing it gives the product owner a false sense of security which is ethically
unacceptable.
Because of the inconsistency of IoT products, their architecture and the technology used
it is impossible to develop consistent security measures that cover the entire spectrum of
different devices. Therefore shall the IoT products be developed around safety standards
instead of the other way around.
For this thesis, we have chosen to work alongside a Stockholm based company called
XLENT to develop a secure smart door lock to access their office. The smart door lock
will be our use case in this thesis and will represent the typical IoT device in our society.
1. How do we set-up high and strong authentication between the user point entity(e.g
Smartphone) and the API and will this property provide strong privacy guarantees?
2. How do we generate an access token for the user that has privilege to unlock the
door and how do we secure this token of being exposed?
3. Which connection protocols can be used in the product and offers the ability to
authenticate, and access control? Does the local WiFi network fulfill the security
obligation?
4. What kind of microcontroller would satisfy the aims of the product by offering a
secure IoT system?
1.3 Purpose
The purpose of this paper is to study and evaluate a suitable set to develop a smart door
lock which is intended to offer high security, easy access, and control. A key challenge that
is faced in this project is the security and privacy of the IoT systems. Therefore, the paper
will present an extensive investigation for the security and privacy of IoT systems seeking
13
to enhance the lock mechanism by connecting it to the internet, making it more robust,
productive and innovative.
1.4 Goals
The goal of the project is to construct an IoT system that includes the SDL application.
The system should be secure and user-friendly. The main goal has been allocated to the
following subgoals:
1.6 Delimitation
The prototype being developed in this thesis is intended to offer high security and easy
access control. The development phase will rather focus on delivering a prototype that is
well-protected against malicious attacks than extensive user functionality. This can lead
to a product that has high security. However, it would need some further development and
optimization to fit the purpose of a user-friendly product.
14
2 Background
This chapter contains the background motivating the thesis as well as the result of the
literature study.
1. Sensor Layer: This layer is considered the lowest layer amongst the three layers and
is implemented at the bottom of the IoT architecture. It communicates with physical
devices and segments through smart devices like sensors and actuators, which makes
it tied to collecting data and controlling the physical world.
2. Edge Layer(Network Layer): is the middle piece of the architecture. This layer is
used to receive the processed information presented by the sensor layer and limits
the directions to carry the data to the devices and applications that are integrated
into the IoT system. This is the most important layer in the system
3. Application Layer: This layer is located on the top of the architecture. It is used to
analyze, interpret and store the collected data.[3]
1. User Interaction Point: User interaction point is the dynamic part that connects
the end user with the end device. The objects in this part can be considered as a
laptop or a smartphone-controlled by the user. The user is capable to control the
unit(Smartphone, laptop,etc..) through a 3rd party application that can be installed.
2. Delegate & Relay: Some IoT system end devices are supported and upheld by a
cloud service that gathers the logic for multiple IoT devices. This group is liable for
the computation. Routers and sensors can also satisfy this position, which corpo-
rate with the cloud to combine and transfer different co-operations through different
communication channels.
15
3. Sensors & Actuators: Are the units that are connected to the system and respond to
the commands, execute the interaction and changes its state. For instance, a camera
starts recording, Smart Tv turns on, a coffee machine begins brewing and so on.
16
to control and more intermediaries will be included in global systems, resulting in an
expanded surface of the potentiality for IT attacks. Large amount IoT devices will be
made out of simple electronics with no capability of authorization, making devices easy
to hijack and exploit. In a trusted system it can be enough that one intermediate is
compromised for the whole system to break down.
When talking about security of IoT devices, three particular characteristics are worth
mentioning; User-centric, Internet-connected and Complexity.
1. User-centric: IoT devices often control actuators and sensors, enabling devices to
interact with the user’s physical environment. IoT systems can process and contain
sensitive data, like user information and behavioral patterns. A compromised device
could lead to serious harm as the device may contain private data as well as its
possible ability control the environment.
2. Internet-connected: One of the biggest attributes of IoT is also one of its greatest
weakness. All IoT-devices have a connection to the internet, making it exposed to
a vast amount of diverse attacks. Connectivity can either be direct or indirect. A
direct connection indicates that the device gains its access to the internet, without
any intermediaries, for instance; connectivity access through the cellular network.
An indirect connection means that the IoT device gains access through an existing
device that is connected to the internet, such as an IoT Hub, router or a smartphone.
3. Complex: As IoT devices become more complex with more advanced hardware they
also expose more vulnerabilities that may be harder to discover and to solve [5].
There have been some concerns regarding the security of IoT systems in the near past.
Companies developing IoT-associated products are principally driven by the time-to-market,
rather than developing steady and reliable products. There is a vast variety of startup com-
panies that rely on producing new functional IoT products on time rather than delivering
a stable and sustainable product. It was found that out of 357 companies that specialize
in home automation, 217 have less than 10 employees [5]. Focusing on the security of the
product under developing can then both be expensive and time-consuming making it a
lesser priority for smaller companies.
17
electromagnetic waves to harm the internal electronics. It can also include different types
of techniques to lure the system. For an example, play a recorded message on a mobile
phone in a try to acquire a successive authentication in voice recognition service.
In recent years there have been reported cases of DoS (Denial of Service) attacks on
devices with a naive trust in the local environment. The attacks used close-range jamming
signals to decrease the signal-to-noise ratio and cause the device to malfunction [5].
18
2.5.2 Environment Mistrust
Environment mistrust problem can be very common in IoT systems due to that the entities
or devices can be placed in the public environment. Different strategies and methods can
be followed to resolve the problem. However, the solution is highly dependent on the
application.
19
Figure 2. Naive architecture of the Smart Door Lock
1. Unintentional Unlocking. There will be cases where the user is close to the door
(and door lock unit) but do not want the door to unlock itself. For example, the user
passes the door on the inside of the office or enters the building by another door. If
lock device senses the authorized user and unlocks the door there is a chance that
an intruder could enter.
To avoid unwanted locking there must be some kind of solution to determine the
user’s exact location and only unlock the door when the user is in front of it. Some
similar products on the market have approached this matter by creating a Bluetooth
directional sensing algorithm [4]. However, this algorithm does not work in some
house layouts. Figure 3 shows an example of a house layout with a digital lock
implemented with directional sensing algorithm. As you can see in this layout there
20
are still areas inside the building that can cause unwanted unlocking. A study showed
that a smart door lock product using this algorithm unlocked the door 10/10 cases
when an authorized user point was present in the light blue area [4]. This is especially
important for the smart lock developed in this project as the lock needs to sense if
the user is on the correct floor. Otherwise, an unwanted unlocking could take place
if the user walks around on the story above or below the office.
2. Relay Attack is a more sophisticated attack that requires both physical presence
and special equipment from the attacker. The basic idea is that two attackers work
together to record the unlocking signal from an authorized user and then use the
smart lock to grant a successful authorization [12]. A typical relay attack case is
played out in the following steps: 1. One of the attackers follows the authorized
user when he/she leaves the building. 2. The attacker then uses an electronic device
that can receive and record Bluetooth signals from the users’ smartphone. 3. The
attacker then relays that signal to the second attacker stationed at the target smart
lock. 4. The second attacker then transmits the signal to trick the smart lock to
open.
It is difficult to build a complete defense against relay attackers. You can implement
geographic localization on the application so the smartphone only transmits autho-
rized unlocking instruction when it is in range of the lock’s working area. This only
solves the problem partially as the smartphone can still be spoofed by the attackers
and tricked into thinking that its geographical position is somewhere else by using
"geographical spoofing" [4].
Figure 3. Example of house layout where a Bluetooth direction sense algorithm fails to
detect whether the user is inside the building or not.
21
2.7 Hardware Review
This project will rely on three major hardware components: a microcontroller unit, A
Bluetooth transmitter and, a smartphone device.
2.7.3 Smartphone
To debug the mobile application developed in the project a mobile smartphone device must
be used. This device needs to support applications of the Android OS and must support
Internet- and Bluetooth communication. In this project, a Samsung Galaxy 3 is used.
22
2. Platform as a Service(PaaS): a layer of software or development environment is en-
capsulated & offered as a service. Here the platform is used to design, develop, build
and test applications and are offered by the cloud infrastructure(eg; Azure Service
Platform, Google App Engine)
23
24
3 Methodology
This chapter contains the methodology and the basic foundation used to carry out this
project. The project is based on four main phases: Pilot Study, Design of Prototype,
Implementation of Design and Testing. The first two steps will be completed in the given
order while the last two steps will be implemented iteratively. This structure will hopefully
hamper risks and inconveniences associated with the project, such as wrongly implemented
code or misgivings regarding the prototype. It will also give a greater understanding of
the problem definition and will help set the projects outlines and delimitations.
The methodology is based upon the iterative and incremental development build model,
which will allow the project to be more agile and adaptive for changes in mid-development.
Enabling a test-driven and flexible development is particularly important in projects where
multiple system parts are obliged to communicate with each other.
An agile methodology was therefore chosen, instead of applying methodologies such as
the waterfall model, which has a rigid, non-iterative approach.
25
3.4 Test Plan
An elaborate test plan that encapsulates all the functionality of the prototype will be
written. The test plan is used to verify that the prototype lives up to the expectation and
the overall quality requested by the stakeholders.
The goal is to continuously update and develop the test plan parallel to the implementa-
tion of the design. This will lead to an iterative working environment where implementation
continuously will be tested against the testbench. The ideal goal is that the prototype will
have an evaluated test for every state of the running implementation.
We aim to restrict the tests to three main categories: Software Tests, Hardware tests
and "Conclusive-End" tests where the final prototype, combined with both hardware and
software, will be tested. The results of the tests will strictly focus on functionality but
more importantly security. This will influence the way we write tests and the test plan
itself. Results of the hardware and software tests will mostly be used to collect data for
further development while the end tests will be neatly analyzed for future research and
conclusions.
26
4 Setting Up A Test environment
The Smart lock is exposed to moderate traffic during the days, by installing a partially
working lock to the door for testing is far from optimal and will lead to unreliable results.
Instead, we chose to create a test environment that represents a real user scenario and
where the product can be tested systematically during the developing phase of the project.
27
high voltage coming from the source. The microcontroller would interpret the signal to
determine whether turning on/off the LED (figure 4).
Figure 4. Schematic of the working relay. The lock is represented as a LED in the
experimental design.
28
5 System Structure
This chapter describes the final system structure and user base flow, figure 5.
Figure 5. System Architecture with a base flow of the system and security leakages.
1. Android Application asks for authentication by sending username and password via
HTTPS.
2. "Auth API" ask for an access token from Azure AD with provided user credentials,
resourceID, and clientID.
3. If the information sent with the request is valid the Azure AD responds with an
access token valid for 2 hours.
4. The token is sent back to the Android Application via HTTPS. The Android client
can now make authenticated calls to the Door API.
5. The Android application will start listening for registered beacons. When a Beacon
transmission is received, the application will confirm that the beacons are from a
valid source.
6. The Android will request to open the door if the beacon validation is successful.
Access token and the function name is provided in the HTTPS call.
7. The door will send a new HTTPS request to the particle if the received request is
authenticated and authorized. The request to Spark Cloud will contain the unique
access token and deviceID for the Particle device.
8. Spark will send the specific function call (in this case "open door") to the device with
the correct deviceID.
29
9. The Photon device will return a specific value of the function called was executed
correctly or not.
10. Spark Cloud will send an HTTPS response back to door API containing information
about the status of the request.
11. Door API sends a response back to Android telling the application if the request was
successful or not.
3. Eddystone-TLM sends telemetric data from the beacons sensors, such as temper-
ature, battery status or atmospheric pressure.
The Eddystone Ephemeral Identifier (EID) is an excellent choice for this project. This
format gives control to choose which clients can make use of the beacon signal and can
only communicate with those that have the same encryption key as the beacon. This will,
therefore, generate prevention of other parties using the beacon. It will also preserve the
integrity of the application as well provide a reliable signal for users in a specific area that
is not easily spoofed [15].
30
5.3 Communicating to and from the REST API
To make different calls via the internet can be dangerous from a security perspective but is
in our cause definitely necessary. The Particle door device needs to be fed different tasks
as door unlocking to be able to perform in a wanted manner.
When transmitting data via the web the sender has no control over which path it
chooses takes to reach the receiver. This means that nodes on the internet can intercept
the data and read it if it is not encrypted in some kind of way. The most standard protocol
for receiving or requesting data over the web is HTTP (Hypertext Transfer Protocol). The
standard HTTP protocol comes in various forms and has all the functionality needed for
calling our web APIs. However, there is one major problem; the HTTP sends data via
plain text. This is a large issue as anyone interacting the HTTP request on its path the
response can easily read or intercept data without us ever knowing. This will make all the
security measures we implement useless and unnecessary as an attacker simply can read all
the communication within the system. extracting sensitive data as username, passwords,
or tokens.
Fortunately, there is a simple solution to this problem called SSL (Secure Sockets
Layer). By combining these two protocols you get a safe and secure protocol with all the
functionality of the HTTP, this protocol is called HTTPS. HTTPS relies on asymmetric and
symmetric cryptography and all the data send between two nodes a completely encrypted.
31
the user associated with the process being performed(e.g Authentication). The purpose of
the access token is to notify the API that the beneficiary of this token has been authorized
to access the API and perform a specific operation.
32
6 Software Development
This chapter explains the development phase of this project. The chapter is split into
six sub-chapter, where each chapter represents an iteration, ordered in a chronological
approach.
1. Firstly you need a google account and create a project in Google’s Cloud API Plat-
form and then allow the fresh project to use Proximity Beacon API and Google
Nearby.
2. Use Google Platform to register the Beacons that will be used in the project. The
platform offers an extensive view over all registered beacons used in the specif project
and will link them together with the application. In that way, you will reduce the
likelihood of unwanted communication with other unregistered beacons and enhance
therefore enhance the overall security of the solution.
3. Establish a unique connection between our Android Application and Google Cloud
API Platform. We want to make sure that only our specific android application has
the allowance to talk to our private Beacon Platform. Otherwise, we face to risk
that other application or endpoints exploits our API and begins to alter the beacons
transmission behavior, such as data payloads, transmission power or even changing
the Beacons unique ID string. To this, you need the create a unique API key in
the cloud platform and link it to the Android application manifest. The android
application will use this key to contact our specif API link to the project. To make
sure that the API only allows communication request from our application we need
to give the API the unique SHA-1 fingerprint generated by the Android application.
4. Now we have to generate code in the android application to tell it to start to com-
municate with Googles API. This can be done in multiple ways, we choose to do
it by creating an instance of the GoogleAPIClient. What this basically does is to
create an object that will connect to the specific Google service you want to use.
Following code establish a connection to Google Nearby API that will later use to
33
receive string messages from the beacons. We should now have a secure connection
with the Google API.
1
2 p r i v a t e void CreateGoogleApiClient ( ) {
3 i f ( mGoogleApiClient == n u l l ) {
4 mGoogleApiClient = new G o o g l e A p i C l i e n t
5 . Builder ( getApplicationContext () )
6 . addApi ( Nearby .MESSAGES_API)
7 . addConnectionCallbacks ( t h i s )
8 . addOnConnectionFailedListener ( t h i s )
9 . enableAutoManage ( t h i s , t h i s )
10 . build () ;
11 mGoogleApiClient . c o n n e c t ( ) ;
12 }
13 }
Listing 1. CreateGoogleAPIClient
To actually receive and interpret messages from the beacons we need to configure
the beacons to send the right kind of data in the right protocol format, we also need to
implement some more code in the Android application. Using the Estimote configuration
application we allow the beacon to start sending string messages via the Eddystone-UID
(a protocol explained in the previous chapter). We then implement a Nearby messages
listener in the Android application. The listener starts to look for messages using the
smartphone Bluetooth antenna and Bluetooth BLE technology. If it finds a message sent
from a known beacon ID, it will log it for us in the Android Studio IDE console.
We debugged the project on a smartphone using Android OS and received strings from
two unique beacons.
34
Figure 7. Basic flow for sending request from Android to particle
1 public void l o g i n ( ) {
2 Async . e x e cu t e A s y n c ( P a r t i c l e C l o u d . g e t ( S t a r t A c t i v i t y . t h i s ) , new Async .
ApiWork<P a r t i c l e C l o u d , Object >() {
3
4 p r i v a t e P a r t i c l e D e v i c e mDevice ;
5
6 @Override
7 p u b l i c Obj ect c a l l A p i ( P a r t i c l e C l o u d sparkCloud ) throws
P a r t i c l e C l o u d E x c e p t i o n , IOException {
8 sparkCloud . l o g I n ( " xxxxxxxxxxx@gyyyyyy . com" , " xxxxxxxxxx " ) ;
9 mDevice = sparkCloud . g e t D e v i c e ( " xxxxxxxxxxxxxxxxxxxxxx " ) ;
10 r e t u r n −1;
11 }
12
13 @Override
14 p u b l i c v o i d o n S u c c e s s ( Objec t v a l u e ) {
15 T o a s t e r . l ( S t a r t A c t i v i t y . t h i s , " Logged i n " ) ;
16 // Checks i f we can c o n n e c t t o d e v i c e a f t e r l o g g i n g on
17 i f ( mDevice . i s C o n n e c t e d ( ) ) {
18 I n t e n t i n t e n t = new I n t e n t ( S t a r t A c t i v i t y . t h i s ,
RemoteControllerActivity . c l a s s ) ;
19 i n t e n t . putExtra (ARG_DEVICEID, " xxxxxxxxxxxxxxxxxxxxxxx " ) ;
20 startActivity ( intent ) ;
21 } else {
22 T o a s t e r . l ( S t a r t A c t i v i t y . t h i s , " Unable t o c o n n e c t d e v i c e " ) ;
23 }
24 }
25
26 @Override
27 public void onFailure ( ParticleCloudException e ) {
28 T o a s t e r . l ( S t a r t A c t i v i t y . t h i s , " Something has gone h o r r i b l y wrong
! ! ! ") ;
29 }
30 }) ;
31 }
Listing 2. Writing login credentials in the Android App
35
cohesion with the Windows OS. We started by establishing a simple test environment for
debugging the APIs and then began to develop the API handling the authentication of the
users. After testing the authentication API by receiving a legitimate access token from the
API we started to develop the door API. This iteration ended with an iterative test of the
complete system deployed to the internet.
1. MS Visual Studio The Azure cloud is developed and maintained by Microsoft and
is highly compatible with their own IDE Microsoft Visual Studio. Visual Studio offers
a thorough debugging tool, project templates and a build in easy deployment tool to
the Azure cloud. Visual Studio also works well with the Windows IIS manager and
is for this project an suiting testing and developing tool to use.
2. Windows Internet Information Service To enable Windows to host a local server
on the computer you need to enable and install the Windows native tool Internet
Information Service (IIS) and its configuration manager. The service offers loads of
useful tools and alternatives and allows an easy setup for running your own local
server.
3. Postman To test the solution, both locally running as well as the deployed solution
we need an easy interface to send and receive different HTTP forms. There are
many tools and program for doing this and we chose to use Postman for this specific
purpose. Postman gives an easy to understand interface with all the functionality
needed for elaborate testing of the APIs.
A test project was later created for an educational purpose. A template project of a
simple web API was deployed to the localhost which responded to HTTP-get request by
returning static numerical values in form of XML or JSON data.
36
• What is a Native API and what differs it from a Web API
Native client web API diverge from a common web API because it is installed on
a cloud, while web API is accessed through a browser. Native clients have the
advantage of asking for an access token from Azure AD meanwhile a Web API can
issue that access token offered by the native client API from Azure AD. The native
client API is a Restful API that has the advantage to ask for an access token from
Azure Active directory because it is configured with the Azure AD Authentication
Library (ADAL) contrariwise from the web API that can’t be configured with the
same library.
2. ResourceId: Identifier of the target resource that is the recipient of the requested
token.
When the process of Authentication is completed and permission has been granted, the
user retrieves an access token to complete the authorization.
1 [ HttpPost ]
2 [ Route ( " a p i / a u t h e n t i c a t e " ) ]
3 public IHttpActionResult Authenticate ( Credentials c r e d e n t i a l s )
4 {
5 var authContext = new A u t h e n t i c a t i o n C o n t e x t ( Authority , new
TokenCache ( ) ) ;
6 var u s e r P a s s w o r d C r e d e n t i a l = new U s e r P a s s w o r d C r e d e n t i a l (
c r e d e n t i a l s . Username , c r e d e n t i a l s . Password ) ;
7 AuthenticationResult r e s u l t ;
8 try
9 {
10 result =
11 authContext . AcquireTokenAsync ( r e s , c l i e n t I d ,
12 userPasswordCredential ) . Result ;
13 }
14 c a t c h ( AdalException e e )
15 {
16 r e t u r n BadRequest ( ) ;
17 }
18 return
19 Ok( new AuthResult
20 {
21 Token = r e s u l t . AccessToken ,
22 ExpiresOn = r e s u l t . ExpiresOn
37
23 }) ;
24 }
25 }
26 }
Listing 3. Authenticate to get an access token
38
6.3.1 Security of API
Building an authorized dependent REST. API is common practice and that’s why there
is an easy-to-implement template option in Visual Studio for this specific purpose. The
template wraps the API in an Owin (Open Web Interface for .NET) middleware to en-
able authorization in an easy and straight-forward way. The Owin code will be executed
in the API start-up code which is separated from the APIs own logic. The only direct
configuration needed is to make sure that both APIs are connected to the same tenant
and that DoorAPI’s ClientID matches the RecourceID in the authentication API . The
authorization of the API should work correctly at this point.
The ASP.net has powerful filter properties which filter out requests received from dif-
ferent sources and data forms. For example, there is an "[HTTP GET]" filter which tells
the API that only request in the form of "[HTTP GET]" will be accepted and processed
by the API. There is also a "[Authorize]" filter, which works in the very same way, it filter
outs all requests not containing a valid access token. This is a very simple but powerful
way to tell the API which functions, classes or data that only should be accessible by
authorized requests.
Code for an identical request can be implement in C# with Visual Studio’s SDK
"Net.HTTP" as listing 16.
1 p u b l i c async Task<s t r i n g > C o n n e c t P a r t i c l e A s y n c ( )
39
2 {
3 H t t p C l i e n t c l i e n t = new H t t p C l i e n t ( ) ;
4 var c t = new L i s t <KeyValuePair<s t r i n g , s t r i n g >>() ;
5 c t . Add( new KeyValuePair<s t r i n g , s t r i n g >(" a c c e s s _ t o k e n " , _accessToken ) ) ;
6
7 HttpRequestMessage r e q u e s t = new HttpRequestMessage ( )
8 {
9 R e q u e s t U r i = new Uri ( _baseUrl + _deviceID + " / " + _ f u n c t i o n ) ,
10 Content = new FormUrlEncodedContent ( c t ) ,
11 Method = HttpMethod . Post
12 };
13 var r e s p o n s e = a w a i t c l i e n t . SendAsync ( r e q u e s t ) ;
14 return response . ToString ( ) ;
15 }
Listing 4. HTTPS request in i C#
40
6.4.1 Using Android framework Components in SDL Application
Android uses a component-based framework for building efficient applications. These com-
ponents can be seen as sets of building blocks that connect with each other by the usage
of intents. This enables developers to build effective and reusable code that inherits all
the essential functionality from the framework. In the SDL application, two major compo-
nents are used: MainActivity and BackgroundService. The two components are declared
in separate classes and inherit its behaviors from different superclasses from the Android
framework. The MainActivity class is derived from the superclass AppCompatActivity.
This inheritance tells the application that MainActivity is an Activity-component that is
backward compatible with earlier versions of the Android SDK.
Activity components are fundamental for android development and handle the inter-
action with the users of the application. Activities are running on the application single
UI-thread that is only active when the user directly interacts with the specific application.
The usage of activity extends to show the users graphic interfaces and are directly con-
nected with Android’s XML layouts. These layouts purpose is to display various graphical
information to the user through the smartphone’s screen. When a user starts an applica-
tion a preset activity life-cycle will start and will handle the startup process of the app
and draw the user interface on the screen. Activities are powerful components with the
ability to handle all the functionality of an application, however, implementing all the logic
in activities is usually a bad practice as activities often are battery-consuming and do not
possess the ability to run in the mobile unit’s background.
For creating longer running operations, the Service component should be used instead
of Activity. These components can run on separate threads in the background, hidden
from the application’s user. Services can still be active even if the user decides to close the
application or lock the smartphone. For an example, this will enable the application to
scan the nearby environment for beacons without requiring the user to interact with the
application.
The functionality of the Smart Door Lock application can, therefore, be divided into
two separate component; MainActivity and BackgroundService. The MainActivity class
will handle both the startup and login process and will also establish a connection with
Google’s APIs. The service BackgroundService is then called from MainActivity to start
running in the background of the phone. The BackgroundService sole purpose is to scan
for beacons and send appropriate requests to the DoorAPI if a valid beacon is detected.
41
Figure 11. Android App interaction
1. A beacon is placed in the proximity of the door lock. This beacon will transmit a
secret token associated with a data payload. The token is synced and registered by
the Google Proximity API.
3. The user walks into the beacon transmission range, the smartphone application re-
ceives the beacon broadcasting token.
4. The application contacts Google Nearby API to check if the token is valid or not.
The application will also send its generated API key to ensure the API that the
application is authorized to receive the message.
5. If both sender and receiver of the message are trusted the message associated with
the beacon will be sent back to the Android Application.
42
Figure 12. Message Exchange Using Google Nearby
43
44
7 Result and Analysis
This chapter goes through the primary result and objectives achieved by this thesis. The
goal was to creat a functioning IoT product that takes the security aspects in regard. A test
was applied on every subsystem during the development until reaching the last milestone
where we had a functioning product
Figure 14. Request traffic to Google APIs, where Nearby API is blue and Proximity API
is green.
45
The android application developed follows an easy to use GUI with two main layouts.
One when the user is prompt to login to the authentication service (figure 16) and another
layout for when the applications are scanning for beacons (figure 17).
Figure 16. User login UI. Figure 17. Login Successful UI.
The particle device is connected to the local WiFi of the office and can be called upon
using HTTPS requests. The particle device has a long lasting connection and waits for
incoming requests.
Figure 18. Particle Spark Console displaying various events relative to the specific Photon
Device.
46
7.2 Discussion
This subchapter presents the security challenges and how we managed to solve the security
gaps from IoT system perspective.
"Communications between the Particle Cloud and each Particle device are en-
crypted by default. Every device ships with a unique device-specific RSA or
Elliptic Curve key-pair, and has a pinned Cloud public key. The device public
key is typically pinned in the cloud during manufacturing, but can be updated
later by an authorized user. Strong unique keys and bidirectional pinning help
prevent man-in-the-middle attacks against devices and data." [19]
As said, the encryption keys used for communication is generated and pinned in the
manufacturing process of the Particle product and extends from the scope of WiFi. Mean-
ing that no key exchange between the Particle Spark cloud and Photon hardware design
will go through the wireless network. Making all data transmission through WiFi unde-
cryptable for other nodes in the network.
There is no concrete way to always make sure that the LAN connection completely
secure as smartphone users are admissible to use whatever network they want to. This is
problematic when transmissions include sensitive data (such as user credentials and access
tokens). A better approach than securing the LAN for the smartphone is the secure the
transmission itself by encryption. If the transmission is encrypted with HTTPS the trust
is moved from the LAN to the certificates provided by the requested server. The trusted
authority, in this case, is then the Azure Cloud. Moving the trust from WLAN to the
Azure cloud acquires a static, more secure solution for the product.
Due to particles security protocol and the HTTPS protocol used to send sensitive data,
we are assuring that no one can eavesdrop on the data transmission and therefore both
gaps being exposed to LAN misstrust are secured.
47
is controlling. In that way, only authorized user has access to the nearby environment of
the hardware, preventing the risk of unwanted attention from other humans with harmful
intentions. As the unlocking process relies on wireless communication various of layout
options exists. A simple rule to follow is to hide the beacon and device as much as possible,
far from the reach of physical intervention.
The other technical branch revolves around on the communication with nearby devices.
How can the device establish if a received nearby Bluetooth transmission comes from an
authorized device? If the device always trusts the source of a transmission, a malicious
device could impersonate a trusted source in a try to prompt an unwanted behavior from
the door lock device. To prevent this from happening full control of device authorization
is needed. This can only be succeeded with reliable encryption and device authentication
management. This is why the Google API was a relevant approach for this product. Due to
the Eddystone-EID protocol, we can filter out all other beacon and Bluetooth transmissions
polluting the environment. The one-time key exchange between beacon and smartphone
happens in another medium, so no key exchange will take place in the nearby environment,
making the system thoroughly secure.
48
as the user hopefully reflects why an application would ask for irrelevant permissions. In
the SDL Application user permissions for Bluetooth low energy and Internet are used.
A small extra note can be made about the usage of the service component. As discussed
above, multiple applications need to work together and share the same battery, processor,
and memory in the smartphone. By implementing the beacon listening on the service we
take the responsibility by saving a significant amount smartphone’s resources.
49
50
8 Conclusion and Future Work
This chapter concludes the work done in this thesis.
8.1 Conclusion
Internet of things is one of the hugest revolutions in the technological field. It is the concept
that describes the idea of connecting everyday physical objects to the internet trying to
digitalise it. As we mentioned before it is expected to have more than 18 billion devices
connected to the internet by 2022. The risks we are facing are the security aspects when
connecting these devices and applications to the internet. The problem is that each of these
devices and applications have it is own security gaps that should be considered making it
hard to standardize the the security aspects in all the devices.
Understanding the basics principles of IoT architectures is a must when developing
a product that is going to interact with the nearby environment. The product of this
thesis is a fully functional smart door application. This system follows the typical IoT
infrastructure explained in chapter 2.1. Where the smartphone application works as the
user-centric interaction point. The developed APIs can be seen as the "delegate"-part and
the Bluetooth beacons can be interpreted as the "sensors". It was important that the
product followed this typical infrastructure as we wanted our prototype to act and behave
like a common IoT-product.
The security implementation of the product gave an overall, more robust result. By
following these 5 major security fields resulted in a more reliable product where, we de-
velopers, had to think outside the box to fulfill the demands of each field. However, the
product lacks some security concerning the functionality of the product. Due to "auto-
matic unlocking", there is no comprehensive prevention against "unwanted unlocking" and
"Relay attacks". However, an implementation of this problem area is discussed later in
this chapter under future work.
We haven’t found any other products on the market that is similar to our solution.
The Bluetooth Beacon solution of this project seems to be unique in the consumer market
for the smart door lock. As the Google Beacon API and Google Messages API is a fairly
new technology, it is possible it will exist in the nearby future.
51
by the production of smartphones. The SDL-product assumes that users already own a
smartphone and the sustainability of smartphones is, therefore, outside the scope of this
project.
This product takes responsibility for preventing electromagnetic pollution and distur-
bances by only using industry standard transmission protocols and EMC-marked hardware.
This product must have a high electromagnetic compatibility as the product could be de-
ployed in heavily polluted areas, such as offices located in densely populated areas. This
has not been researched thoroughly but the developed prototype shows no signs of a lacking
electromagnetic compatibility.
By moving as much data processing to the cloud as possible, the general power con-
sumption of the product is decreased. Instead of relying on the batteries of the user’s
smartphone, the power of the cloud is used, saving energy recourses as well as lower the
wear of the smartphone batteries.
8.3 Risks
There is a substantial risk involved with developing an electronic door lock. Locks are a
product of safety and rely on a great trust between product and user. The owner of the
lock must feel completely confident that the lock is secure. This trust is hard to acquire
and very easy to lose.
A responsibility lies also on the owner and administrator of the smart door lock. Care-
less usage of the product can compromise the safety of the people inside the building and
also lead to direct damage the building’s property.
This prototype could also very well malfunction, either by an external or internal, fault
of the system. This fault could, for example, be a loss of internet connection or electricity.
In that case, some kind of backup functionality should be considered. This backup could
imply a still functional traditional lock installed on the door, or expanding the functionality
of the prototype, making it still functional and secure during a power/internet outage.
In extreme cases, such as fire emergencies and other relevant scenarios it is of utmost
importance that the door lock behaves in a predictable way. The smart door lock, therefore,
need to possess the ability to override its normal behavior, allowing people to use the door
freely in such specific cases.
52
Unintentional unlocking could be solved with a similar solution using GPS technology.
You could implement the system in a way that the user needs to leave the office with a
certain distance before the application asks for unlocking again, preventing the risk of the
application resending requests when the user is located inside the office. Another simpler
approach could be to install a simple button next to the door, prompting the door to open
if both a user’s smartphone is nearby and the button is pressed. However, this solution is
not ideal as a non-user could wait outside the door until a person inside the building walks
by.
53
References
[1] Ericsson AB. Iot security, white paper. https://www.ericsson.com/assets/
local/publications/white-papers/wp-iot-security-february-2017.pdf. Ac-
cessed: 2017.
[2] Jie Lin, Wei Yu, Nan Zhang, Xinyu Yang, Hanlin Zhang, and Wei Zhao. A survey
on internet of things: Architecture, enabling technologies, security and privacy, and
applications. Internet of Things Journal, IEEE, 4(5):1125–1142, October 2017.
[3] Kewei Sha, Ranadheer Errabelly, Wei Wei, T Andrew Yang, and Zhiwei Wang.
Edgesec: Design of an edge layer security service to enhance iot security. In Fog
and Edge Computing (ICFEC), 2017 IEEE 1st International Conference on, pages
81–88. IEEE, 2017.
[4] Grant Ho, Derek Leung, Pratyush Mishra, Ashkan Hosseini, Dawn Song, and David
Wagner. Smart locks: Lessons for securing commodity internet of things devices.
Master’s thesis, University of California, Berkeley, 2016.
[5] Nan Zhang, Soteris Demetriou, Xianghang Mi, Wenrui Diao, Kan Yuan, Peiyuan
Zong, Feng Qian, XiaoFeng Wang, Kai Chen, Yuan Tian, Carl A. Gunter, Kehuan
Zhang, Patrick Tague, and Yue-Hsun Lin. Understanding iot security through the
data crystal ball: Where we are now and where we are going to be. "https://arxiv.
org/abs/1703.09809", 2017.
[6] Abdillahi Hassan Adnan, Mohamed Abdirazak, A.B.M Shamsuzzaman Sadi, Tow-
fique Anam, Sazid Zaman Khan, and Mohammed Mahmudur Rahman. A compar-
ative study of wlan security protocols: Wpa, wpa2. http://ieeexplore.ieee.org/
document/7506822/, 2015.
[8] A. Perrig et al. In The Tesla Broadcast Authentication Protocol , CryptoByte, vol 5,
pages 2–13.
[10] Earlence Fernandes, Justin Paupore, Amir Rahmati, Daniel Simionato, Mauro Conti,
and Atul Prakash. Flowfence: Practical data protection for emerging iot application
frameworks. In 25th USENIX Security Symposium (USENIX Security 16), pages 531–
548, Austin, TX, 2016. USENIX Association.
[11] Yan Michalevsky, Suman Nath, and Jie Liu. Mashable: Mobile applications of se-
cret handshakes over bluetooth le. In Proceedings of the 22nd Annual International
Conference on Mobile Computing and Networking, pages 387–400. ACM, 2016.
[12] Aurelien Francillon, Boris Danev, and Srdjan Capkun. Relay attacks on passive keyless
entry and start systems in modern cars. https://eprint.iacr.org/2010/332.pdf.
54
[14] Google inc. Eddystone format. https://developers.google.com/beacons/
eddystone.
[19] Particle IO. Security check list of internet of things. Security check for iot devices,
3:7–9, 2017.
55
TRITA-EECS-EX-2018:3
www.kth.se