EXAMENSARBETE INOM TEKNIK,

GRUNDNIVÅ, 15 HP
STOCKHOLM, SVERIGE 2018

IoT Security Applied on a

Smart Door Lock Application
KRISTOFFER DJUPSJÖ

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

7 Result and Analysis 45

7.1 Primary Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
7.2 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
7.2.1 LAN misstrust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
7.2.2 Environment misstrust . . . . . . . . . . . . . . . . . . . . . . . . . . 47
7.2.3 Application over-privilege . . . . . . . . . . . . . . . . . . . . . . . . 48
7.2.4 No/Weak Authentication . . . . . . . . . . . . . . . . . . . . . . . . 49
7.2.5 Implementation Flaws . . . . . . . . . . . . . . . . . . . . . . . . . . 49

8 Conclusion and Future Work 51

8.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
8.2 Ethics, Sustainability and Benefits . . . . . . . . . . . . . . . . . . . . . . . 51
8.3 Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
8.4 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

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

SDL Smart Door Lock

API Application Programming Interface

DGC Device-Gateway-Cloud

DIC Direct-Internet-Connection

REST/ful Representational State Transfer

IT Information Technology

W/LAN Wireless Local Area Network

DoS Denial of Service

PIN Postal Index Number

XSS Cross-Site Scripting

MAC Media Access Control

MCU Microcontroller Unit

OS Operating System

SaaS Software as a Service

PaaS Platform as a Service

IaaS Infrastructure as a Service

I/O Input/Output

SDK Software Development Kit

HTTP Hypertext Transfer Protocol

HTTPS HTTP over SSL

SSL Secure Socket Layer

LED Light-Emitting Diode

A/AD Azure Active Directory

EID Ephemeral Identifier

UID Unique Identifier

URL Uniform Resource Locator

BLE Bluetooth Low Energy

XML Extensible Markup Language

JSON JavaScript Object Notation

11
SHA-1 Secure Hash Algorithm 1

IDE Integrated Development Environment

IIS Internet Information Service

OWIN Open Web Interface for .NET

UI User Interface

GUI Graphical User Interface

RSA Rivest–Shamir–Adleman

EMC Electromagnetic compatibility

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.2 Problem Definition

The security aspect is the highest concern of IoT connected entities. The data can be
personal, enterprise or consumer. To reach an acceptable implementation for the smart
door lock (SDL), security should be taken as a major challenge. We can summarize the
problems into different questions

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?

5. Which IoT architecture would fit the aim of SDL?

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. Constructing an architecture regarding the security and functionality.

2. Establishing a reliable technique to determine if a user is in the physical proximity

of the door lock using Bluetooth.

3. Attaining a proper policy to authenticate users trying to access the door.

4. Creating an android application that can serve as the user endpoint.

1.5 Research Methodology

Our research was split into two major parts. A theoretical and a practical part. The theo-
retical one was based on a pilot study where we went through the major security concerns
regarding IoT devices as well as finding appropriate project scope supporting the goal of
the project. The practical part was to familiarize our selves with the development tools
and environments (e.g .NET, RESTful, Android) required fulfilling a functional system
that considers the security concerns mentioned in the theoretical study.

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.

1.7 Structure of Thesis

Chapter 2 contains the background and research study this thesis is based upon.
Chapter 3 contains the planned methodology and working progress used in the project and
thesis.
Chapter 4 introduces the test environment used throughout the project.
Chapter 5 introduces the product’s system architecture and explanation of different parts.
Chapter 6 presents the actual development of the system parts presented in chapter 5.
Chapter 7 contains the result and comprehensive analysis of the finished product
Chapter 8 is dedicated to further conclusions and relevant information about future work.

14
2 Background
This chapter contains the background motivating the thesis as well as the result of the
literature study.

2.1 Internet of Things

Internet of things is a tremendous bias where a huge abundance of sensors and appliances
would be connected to the internet and interact with the cloud. Different business appli-
cations endure, such as vehicles, homes, buildings, machines, environmental sensors and
so on. IoT is growing rapidly and is estimated to comprise 18 billion connected devices by
2022 [1]. IoT comes in a wide spectrum of different ecosystems, all with various require-
ments and capabilities. For example, autonomous cars inherit a highly complex system
where system safety and reliability are by far the biggest factors. The self-driving car
system differs significantly from more simple IoT products like a sensor reading system
where power consumption and environmental aspects are more of importance.

2.1.1 IoT Architecture

Understanding the basic principles of IoT is important for providing a functional sys-
tem architecture. A common architecture of IoT systems usually consists of a three-layer
structure which can be introduced as the edge layer, the application layer, and the sensor
layer [2]. These layers are further discussed below:

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]

2.1.2 Foundation Of physical environment in IoT

The overall structure is represented as we can see in figure 1. It is possible to classify the
foundation of IoT ecosystem into three main parts (1) User interaction point (2) Sensors
& actuators (3) Delegate & Relay; These three are described below:

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.

Figure 1. Infrastructure of Iot ecosystem

2.1.3 Basic Structure of Typical IoT Application

The smart door lock (SDL) is one of the more heavier discussed topics in the IoT sphere
as the product is highly dependent on a solid security implementation and maintenance.
A breach or compromisation of SDL could lead to severe damage, like loss of goods in a
burglary or even life threating series of events. Smart locks usually consist of the three
major components: an electronic device capable of receiving instruction to open and close
some kind of deadbolt, a mobile device sending the instruction and a remote web server
handling calls to an API and/or database.
There are two common network system designs for digital home locks: the DGC model
(Device-Gateway-Cloud) and DIC (Direct-Internet-Connection). DGC rely on the user
interaction point (Mobile application) to act as a gateway to the internet while the DIC
connects to the internet directly via the electronic lock device [4]. Both architectures follow
the same basic principles of the typical infrastructure of IoT device explained in section
2.1.2.
Depending on how the interaction model is implemented a typical user will only see and
interact with the mobile application (User interaction point) where everything essential for
the user will be provided.

2.2 Consumer Internet Of Things

There are two different spheres to the business model concerning the IoT systems.We define
these two models as business-to-business and business to consumer. Business to consumer
delivers the products to the end user whereas business-to-business targets enterprises. Our
main focus in this study will be oriented towards the end-users (business to customer)
because they are more exposed to IoT attacks due to the lack of technical expertise and
deployment of protection methods to avoid any potential attacks.

2.3 Understanding IoT Security

As the vast variety of devices can start communicating with each other new business and
functionality will bloom. However, as connectivity increases, transmissions will be harder

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.

2.4 Security Challenges In IoT Systems

A generalization of IoT security attacks can be made into five problem areas described
below; LAN mistrust, Environment mistrust, Application over-privilege, No/Weak Authen-
tication and Implementation Flaws.

2.4.1 LAN Mistrust

Security in the local network requires the ability to authenticate, authorize and access
control. However, it fails to fulfill the security obligations of the IoT system due to the fact
of trusting the local WiFi network that the IoT system is connected to, meaning that once
the device is connected and authenticated to the network then it should be trusted. This
will leave the IoT system exposed to other parties running on authenticated devices[6].

2.4.2 Environment Mistrust

As IoT-devices are often positioned in the public realm and are exposed to numerous of
physical disturbances and adversaries. When a device has a naive environmental trust it
implies weak resistance against compromisation within physical mediums. An attack of
this category can be to simply destroy the device or its sensors with violence or sending

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].

2.4.3 Application over-privilege

There is a common concept in the world of computer security called The principle of least
privilege[7], where the privilege of computer program or applications should be minimized
to the least possible needed to perform the program’s necessary tasks. An over privilege
application can lead to potential harm in the form of private data leakage or side channel
attacks.

2.4.4 No/Weak Authentication

Authentication is the process or action of proving or showing something to be true, genuine,
or valid. An IoT ecosystem often involves multiple different connections to WiFi, Internet,
and sensors via Bluetooth. It is essential that the ecosystem can verify all its connected
parts as well as the API it is connected to, otherwise the system will be an easy target for
malicious attacks. There is also a risk that the system will try to establish and transmit
sensitive data to devices outside the proximity of the product. Weak authentication is
often a problem in Bluetooth communication as devices either provide no or weak PIN-
code authentication that easily can be brute-forced.

2.4.5 Implementation Flaws

Most successful attacks on IoT are because of implementation flaws in the device. This
attacks often takes form as cross-site scripting(XSS), leakage of hard-coded credentials,
open ports and transmitting sensitive data in plain text [5].

2.5 Security Solution For IoT Systems

This chapter will shed some light on possible general solutions to increase the security
concerning the five major problem areas.

2.5.1 LAN Mistrust

Trust is a vital factor in the implementation of IoT products. Trust lays an essential role
in establishing secure communication between the interacting devices. There should be
an efficient mechanism that defines the trust in an IoT infrastructure. As network nodes
start interacting and communicating, the need to authenticate and validate the sender of
an incoming message becomes a necessity. For an end to end security, a possible solution
could be applying various kind of cryptographic schemes, for example, broadcasting au-
thentication protocol [8]. This is achieved by attaching a MAC code to the packet being
sent. The receiver end stores the packet without being able to authenticate. Later on the
sender reveals the keyed Mac to the receiver with a privilege to authenticate the packet[9].
Access control is another solution that is discussed but not implemented yet. Access con-
trol systems offer identification, authentication, access permission and responsibility for
the entities in the environment through login credentials including passwords, PINs, and
physical or electronic keys.

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.

2.5.3 Application Over-Privilege

This problem takes a place due to the poor scale of the protection mechanism in the devices
that support multiple application. These devices could be the user interaction point and
for instance, smartphones. A smartphone system can allow any app with a permission to
access Bluetooth, NFC, Audio and internet devices. The attacker can take advantage of
this using applications to achieve the manipulation of IoT devices and entities interfaces
leading them to perform unapproved operations. This problem can be solved by access
control solutions to the operating system in the device (e.g smartphones). On the other
hand, there are some protocols like FlowFence that aim to practical data protection for
emerging IoT application frameworks. FlowFence offers an information flow entrance to
prevent over-privilege third-party application from manipulating end entities of the IoT
system [10].

2.5.4 No/ Weak Authentication

A way to tackle this problem is by adding end to end or application level authentication;
This can be approached by a cryptographic secret handshake that enables two parties to
verify each other[11].

2.5.5 Implementation Flaws

Implementation flaws are a serious problem in IoT devices. However, the problem takes
a place due to the IoT vendors who don’t always treat security as a superiority. Most
access control solutions that help to solve the above problems could also solve possible
implementation flaws indirectly. For instance, the suggested solution in No/Weak Authen-
tication the cryptographic secrete handshake can protect the IoT device since it won’t
enable unauthorized parties to access the device.

2.6 The Smart Door Lock

The smart door lock will control over unlocking the entrance to an office space. The
entrance door is located on the third floor inside a large building and connects the office
with a stairwell and multiple elevators. The smart lock is expected to handle a heavy flow
traffic as well as maintain a solid functionality in the given environment. It is essential
that the door only unlock itself for authorized people in the space between the stairwell,
elevator and the door. This poses that the door lock needs to have an accurate sense of
where the user is located.
A naive system overview of the smart door is shown in figure 2. The user application
will communicate via Bluetooth to the lock only to tell if a specific user is nearby. Both
the lock and the application will have separate communication channels that securely
transmits to the API via a cloud service. The API will accept various requests and either
send commands back to the digital lock and/or feedback response to the user application.

19
 Figure 2. Naive architecture of the Smart Door Lock

2.6.1 Direct Internet Connection

The system will implement the Direct Internet Connection (DIC) network design. By
following the DIC the system can bypass security challenges such as Revocation evasion
and Access Log evasion [4]. This is avoided because the lock device is directly connected to
the internet via WiFi instead of relying on the user endpoint for an internet connection. If
the device has a direct established connection the API and database it can instantaneous
log events and revoke illegitimate digital keys. If the system follows the Device gateway
model the device will only have access to the internet when an authenticated Smartphone
is in range of the Bluetooth signal emitted by the lock. The locking device has then no
chance of knowing if an user id or digital key is revoked or not, until it may be too late.

2.6.2 Automatic Door Unlocking

To simplify and improve the usability of the SDL, it will support automatic door unlocking.
The lock shall be able to sense that an authorized mobile device is nearby and automatically
open the door. This will pose for two potential security breaches, unintentional unlocking
and relay attacks.

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.

2.6.3 Other products on the market

There are multiple similar products on the market but none of them fulfill the functionally
required for our product. Most of them are for private use only, more focused on user
experience, simplicity or futuristic design, and fails to explain the security of their prod-
uct. This is problematic as it gives the product owner no acknowledgment on how secure
their smart door lock really is. We will, therefore, aim to create a lock with motivated
and transparent security solutions without disclosing any vital information concerning the
security of the product.

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.1 Microcontroller Unit

The microcontroller unit is an embedded system that contains input/output pins where we
can connect it to the object that we’re trying to work against to achieve the functionality
needed. To develop the functionality of locking and unlocking the door, a microcontroller
unit would be essential to serve the objective of the project as it can receive a signal and
interpret it to do a specific functionality.

2.7.2 Bluetooth Transmitter (Beacons)

This project will use Bluetooth for sensing nearby user. For sending a strong and stable
Bluetooth signal into the nearby environment an antenna must be used. Some MCU’s have
an already built-in support for sending and receiving Bluetooth transmissions. However,
this supports are often unreliable and will not carry the structure of this project. Instead,
the actual Bluetooth transmissions within this project will be completely separated from
the MCU unit. This is achieved by implementing so-called Bluetooth Beacons. These
Beacons contains small processors, batteries, antennas and are specialized for handling
Bluetooth communications.

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.

2.8 The Software Representation

The architecture of software gives a significant understanding of the system under devel-
opment. It shows how the system is divided into subsystems. It tells which problem the
system can solve, and wherein the system each problem is solved. To start with the soft-
ware development, an architectural pattern is needed to divide the system into subsystems.
This division is helpful to avoid mixing code. Without such division, it is is easy to tangle
the user interface code with the business logic code in the same method.

2.9 Computing Concepts

There are many computing concepts like "Grid computing", "Cluster computing" and
"Cloud computing". In our design, we’ll be choosing the cloud computing. cloud comput-
ing is a computing standard where several entities of a system are connected to a private or
public network. It provides dynamically scalable support and foundation for application,
data and file storage which would serve the aim of our application"SDL"[13].

2.9.1 Cloud Computing Models

1. Software as a Service(SaaS): In this model, a complete application is offered to the
customer as a service on demand. To say highly scalable internet based applications
offered on the cloud and offered as services to the end user (eg Google Docs).

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)

3. Infrastructure as a Service(Iaas): IaaS provides basic storage and computing capabil-

ities as standardized services over the network. It is a pay per use model. Services like
storage and database management are offered on demand(eg Amazon Web Services)

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.

3.1 Pilot Study

A research study was conducted before the phase of design and implementation. The
research aimed to understand the nature, architecture and security challenges of imple-
menting an IoT product.
Gathering sufficient information regarding the two main themes of this thesis; The
architecture design of common IoT applications and the security challenges faced by IoT
entities. The first task consisted of figuring out the common architecture of IoT systems
and understanding the main three layers that are mentioned in the pilot study leading us
to set-up a foundation of the physical environment and classifying the overall structure for
our own IoT system represented by the smart door lock. The second main subject that
took a place in the pilot study was understanding the security aspects of IoT systems.
Since there are a vast variety of devices that are communicating with each other resulting
in expanded breach and possibility for harmful attacks on the system, a main focus on
the security aspects seemed reasonable and relevant. We tried to sum up the security
challenges and generalize the attacks to set a list of requirements that are needed to be
taken and considered when developing an IoT system.

3.2 Design Of Prototype

A complete specification for the prototype is derived and considered from the pilot study.
Design choices take regard to the common architecture of IoT systems and the security
challenges. The preferences comprised of a suitable microcontroller that would serve the
functionality of the SDL, wireless devices transmitting a continuous radio signal which can
be detected by smart devices (e.g Smartphone) via a connective protocol (e.g Bluetooth),
a cloud that can contribute in a secure and stable communication and an API that would
be able to handle the functionality of the SDL.

3.3 Implementation of the Design

The phase of development and implementation is conducted with an iterative strategy to
construct the prototype that would match the specifications of the design. By breaking
down the design into small chunks, we are able to develop and test in repeated sequences.
In each iteration, new features can be developed and tested until we have a fully functional
system that fulfills the purpose of the thesis.

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.

4.1 Choice of Microcontroller Unit

There are multiple of different microcontrollers (MCU) on the market that will fulfill our
demands on the hardware. We want a secure and robust MCU with the ability to stay
internet connected. The Arduino hardware is a well-established choice that has much
technical documentation and has an easy internet setup. However, the Arduino is more
targeted to the hobby user and has a lot left to wish for security-wise. Instead, we decided
to implement our door lock with the Particle Photon device. The Particle Photon is a
small yet powerful IoT -device that can handle both WiFi and Bluetooth communication.
The Photon offers multiple I/O pins and a processor powerful enough to handle the logic
needed for this project. The Photon provides a well developed and robust SDK with
multiple tools for easy configuration of the device. All communication to/from the device
will go through the Spark -cloud with secure HTTPS transmissions and token handling.
Using Photon would improve the security of the prototype being designed as well as saving
a significant amount of resources otherwise spent on developing a similar solution.

4.2 Choice of Bluetooth Beacons

A Bluetooth beacon has a relatively simple hardware structure. The purpose of the bea-
con is simply to transmit a Bluetooth signal to its surroundings. The beacon should be
configurable to the point that an administrator can modify the beacon-transmitting data,
including the transmitting power and ID-tag of the beacon.
The Estimote’s Bluetooth beacons fulfill our demands and have all the functionality
needed for the design being developed. The Beacons comes with a reliable interface for con-
figuration and well-documented SDK for multiple different platforms. The beacons support
third-party Bluetooth transmissions protocols, granting more options to developers.

4.3 Test Environment/Experimental Design

This subsection introduces a test environment applied for examining the progress and
improvement of the system.

4.3.1 Controlling a Door Circuit using a Relay

A relay has two circuits; a control circuit and a load circuit. When the control circuit is
turned on current starts flowing through a coil, it generates a magnetic field that attracts
the armature and the load circuit is closed. A relay can be used to control different circuits
by one signal. Relays are used whenever it is necessary to control high power or high voltage
with a low power circuit. Low power devices as microprocessors can drive relays to control
electrical loads beyond their direct drive.

4.3.2 Test of MCU

The Photon MCU was used to test a basic functionality within the design. A test program
was written to control a LED on the microcontroller itself. Thereafter, a test environment
was set up on a breadboard to control an external LED using a relay that controls the

27
high voltage coming from the source. The microcontroller would interpret the signal to
determine whether turning on/off the LED (figure 4).

4.3.3 Schematic of the electronic door lock

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.

5.1 Using Beacons to Monitor User Location

The project will use multiple location Beacons from a company called Estimote. The
Beacons uses Bluetooth Low Energy technology and supports a numerous different trans-
missions protocols. Both Apple and Google offers their own widely popular Beacon trans-
mission technology, this project will rely on Google’s open format called Eddystone.

5.1.1 What is Eddystone?

Eddystone is an open, free to use transmission protocol developed for Bluetooth beacons
and is compatible with both Android and IOS. Eddystone support four major packet format
to transmit data:

1. Edddystone-UID: consist of a simple format where each Beacon contains a names-

paceID and and a specif InstanceID.

2. Eddystone-EID works similar to UID but pseudo-randomly generates a new iden-

tification with a developer set lifetime. The 8-byte identification string is also AES-
encrypted.

3. Eddystone-TLM sends telemetric data from the beacons sensors, such as temper-
ature, battery status or atmospheric pressure.

4. Eddystone-URL sends a given URL to its environment. [14]

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].

5.2 What is REST API?

Representational state transfer technology (REST) is a software architectural approach
and procedure used for the goal of communication in web-based services. REST is an
API that uses HTTP requests to get, post, put and delete data. This API uses HTTP
paradigms. REST API uses GET function to regain a resource; PUT function to change
the nature of/update a resource, which can be a block of information or a file; POST
function to create a resource and DELETE function to remove it. This API structure
is important to minimize the coupling between the client and server components in a
distributed application. REST is an interface between systems using HTTP to obtain data
and generate operations on these data in all possible formats (e.g XML and JSON)[16].

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.

5.4 What Is an Active directory

Active directory is a distributed, multi-master database where we can store information
about our computers, users and security groups. The AD can perform some functionality
to serve the goal of the project being developed (e.g. Authenticate users and computers
when the user tries to get on to the system).

5.4.1 Using Azure Active Directory to Authenticate Users

Azure Active Directory is a cloud-based authentication manager produced and maintained
by Microsoft. The service offers a highly secure and functional identity management to
companies as well as to private users. By deploying a Web API integrated with Active
Directory to the Azure cloud you can save a large number of resources and simultaneously
increase the overall security of the product.
We choose to implement the Azure AD into a separate Web API. This API will handle
authentication of the user and send back a valid access token to the mobile application.
By receiving the user’s login credential (username and password) by secure HTTPS post
method the API will establish a connection with the active directory service and forward
the credential to the AAD. The AAD will then check the credentials for validity and
return a custom access token with encrypted information, containing the user’s objectID,
user scope and what resource the user should be able to access. We choose to separate the
authentication outside the android application to give less control of the authentication
flow in the mobile application. In this way, we gain more control over the login forms and
basic flow of the mobile application. It will also make it easier to update and edit the
application as well as making it easier to implement applications to different platforms.

5.4.2 What is an Access Token and why do we need it?

An access token is an object that is implemented in the security context when working
authentication. It is considered a credential that can be used by the client to access a
specific API. it is considered as a unique string containing letters and numbers where this
string is passed with every API call. The information in a token includes the identity of

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.

6.1 Android Test Application to connect Google Beacon and Particle

Device
A simple Android application was developed in this iteration in trying to set up a suitable
test environment to experiment the basic functionality flow by sending a request from the
Android app to spark cloud where we have written simple test code to turn on a LED.

6.1.1 Receiving A String from Beacon to App

As we were exploring different alternatives for establishing the communication between
the Bluetooth beacons and mobile phone application we realized that Google offered a
better alternative to our solution. Estimote has its very own SDK that worked well for our
purpose, however, we made the decision to work with Google’s alternative for a number
of reasons. The main reason was that Google offers more securely and robust platform
for handling beacons. It has a larger, more documented SDK and an excellent integra-
tion with its own mobile platform, Android, it also offers full support for the Eddystone
communication protocol.
To setup solid beacon communication between a smartphone and beacons, we used two
of Google’s cloud-based APIs called Google Proximity Beacon API and Google Nearby
API. To create a working communication you need go through following steps:

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.

Figure 6. Communication between android app and Google API:s

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.

6.1.2 Sending A Request from App to Particle

Setting up a simple layout for the Android app by designing a button to send the request to
turn on the led on the spark cloud that belongs to the particle photon microcontroller.We
used Particle Android Cloud SDK which is an easy-to-use wrapper for the Particle REST
API. The SDK enables interaction and synergy between our Android app and Particle-
powered connected microcontroller via the Particle Cloud. However, publishing events
from the Android app directly to the particle cloud would be a problem because we will
be exposing our login credential which were hardcoded in plain text in the Android app.

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

6.1.3 Particle Console IDE

Particle has an Integrated development environment IDE enabling the user to develop the
software for the microcontroller in an easy-to-use application. Every particle device has a
unique ID where the user can bind the code with the exact, unique, particle.

6.2 Creating a Azure AD tenant and Developing Authentication API

Next iteration of the project was to develop the web API extending the product. We chose
to use Microsoft’s framework for REST. API because of the offered simplicity and great

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.

6.2.1 Creating A Suitable Test Environment for WebAPI

It is essential to create an elaborated test environment to enable a test-rich development.
Therefore, we needed to test our solution locally on the computer to make sure that we
have a functioning test before publishing the solution on the cloud. To do this, we want
to allow our computer to run programs on the "localhost", which is a hostname of the
computer’s local loopback network interface. This allows us to send various HTTP request
to the WebAPIs locally, without deploying an unfinished product to the web. The test and
development of the APIs conclude of three major parts:

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.

6.2.2 Creating A Tenant And Users in Azure AD

In a physical workplace, the term tenant can be described as a company or organization
that occupies a building. This building may contain different organizations/companies or
in another word different tenants. In Cloud enabled workplace, a tenant can be interpreted
as a client or organization that owns and manages a particular instance(Blueprint) of that
cloud service(In our case Azure AD).
With the identity platform provided by Microsoft Azure, a tenant is simply a dedi-
cated instance of Azure Active Directory (Azure AD) that an organization receives and
owns when it signs up for a Microsoft cloud service.A tenant is responsible for the users
of an organization and their credentials (e.g passwords, user profile data, permissions). It
also contains groups, applications besides offering security for the organization.Creating a
tenant through Azure AD helps us to control and manage the applications being created
and registered in the AD. We’ll be creating two different applications which are the Au-
thentication API (defined as "Native API" ) and the Door API (defined as "Web API")
under the same tenant to say that the two applications belong to the same service.

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.

6.2.3 Authentication API Development

Authentication is the process of determining whether someone or something is listed and
eligible. The process of Authentication is simply comparing the credentials provided by a
user to the ones in the database of authorized users. If the credentials match, the procedure
is executed and the user is granted a permission to access. In an IoT scenario like ours,
this process is a vital and crucial process to serve the purpose of this project in security
matters. We built an authentication REST API to facilitate the interaction with/from
any platform(e.g web API, mobile app). We used HTTPS authentication to get an access
token in our REST API. We created a constructor that has the authentication context
which is the authority represented by the tenant and the URL instance for login in Azure
active directory. Using the authentication context, we’ll be acquiring an access token from
the authority on the behalf of user passing necessary claims for authentication as below:

1. ClientId: Identifier of the client requesting the token.

2. ResourceId: Identifier of the target resource that is the recipient of the requested
token.

3. User Credentials: Username and password.

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

6.2.4 Test: Retrieve a token

To test the functionality of our Authentication API, we sent an HTTP post request to our
local host using postman which is a developer tool utility to test API calls we use a URL
encoded form and expect to retrieve the access token from the API in the form of JSON
string.
Configurable token lifetimes in Azure Active Directory We faced a problem with
the lifetime of the access token that was expired as soon it was released when we tested it
so we had to configure the lifetime of the token. We used the policy object that represents
a set of rules that are enforced on individual applications or on all applications in an
organization. using PowerShell modules we were able to change the lifetime of an access
token and extend it to two hours.

Figure 8. Retrieving an access token using HTTP request in form of JSON

6.3 Door API Development

After making sure that the authentication API worked properly we started to develop the
API handling the actual request to the Particle device. Mainly we want to handle the
command that tells the hardware to open the door. This command will be received by
HTTPS from the Android application, the API should be able to interpret the command
and create its own HTTPS request and send it to the particle. To ensure that only
authenticated sources can send requests to the API we need to enable some security features
in the API first.

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.

6.3.2 Connecting to Particle

There are multiple ways to communicate with the Particle device, the two most common
and efficient ways it to use Particle’s SparkSDK to establish a running connection to
the Particle device, the other way is to use authenticated HTTPS request. Both ways are
compatible with the project but choosing HTTPS over the SparkSDK has some advantages.
HTTPS is more configurable, easier to understand and debug, it is also very compatible
with C# and ASP.NET in general. It gives more control over the transmission as HTTPS
is securely encrypted by SSL certification.
The HTTPS request sent to Particle must include some specific data for it to success.
Picture 9 display a simple function call to the Particle device from Postman.

Figure 9. HTTPS request and response from Particle Device

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#

6.3.3 Test: HTTP/S from Postman

This iteration ended with HTTPS-test. The goal was to turn on the led through an
authenticated HTTPS-post sent to the Door-API.

6.4 Android Development/Architecture

Android is an operating system which can be found on a variety of different modern devices
and considered one of the most popular OS on smartphones. Android is a Linux-based OS
and it is composed of a stack of software components which are roughly divided into four
layers where the Linux kernel lies at the bottom layer and provides the abstraction between
the device hardware(e.g camera, display). On the top of the Linux kernel layer is a set of
libraries including open-source web browser engine making it the second layer following it
with the third layer which is the Application Framework layer presenting various higher-
level aids to applications in the form of Java classes. The last layer which is the top layer
is the Android Application layer where the developers are being able to write their apps
and install it on this specific layer.[17]

Figure 10. Android Layers

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.

6.4.2 Application Overview

Following the Structure in figure 11. The SDL app will be requiring the user to enter
the login credentials (username, password). Clicking on the login button will activate the
onClick() method that in turn will go to our MainActivity and trigger an HTTPS request
through the HTTPS client. The credentials will be sent in a scrambled message with
an agreed code between the sender and the receiver (Authenticate API in our case) and
transferred on a Secure Sockets Layer where no one can read the message. The user’s
credentials are authenticated in API, when the Authentication process is completed and
succeed, the Access Token is sent back to the MainActivity in the SDL app. At this point,
the app is ready to start the Background service and begin to scan for beacons. When
a valid beacon is found, an authenticated request is sent (containing the acquired Access
Token) through the HTTPS client to the Door API where the validity of the token is
determined. A proper response is then sent from the Door API telling the application if
the request was successful.

41
 Figure 11. Android App interaction

6.4.3 Integration of Google Beacons

The integrating beacons in the application can be divided into two main parts. The bea-
con initialization part and the message listening part. In the startup, a Google client is
created, as described in the previous chapter 6.1.2, when the client is successfully con-
nected to Google’s APIs the subscription service BackgroundService will start running in
a background thread. The beacon handling is dependent to two important API’s created
by Google, called Nearby Messages and Google Proximity API.
Nearby Messages is an API that allows different units, supporting wireless communi-
cation, to send messages to each other. Google nearby sends these messages through the
web instead of sending them directly via Bluetooth. Google Proximity API allows beacon
to use the Nearby Messages API by associate data to registered beacons as "attachment".
These attachments can then be read as messages by other registered devices.
Following sequence describes typical message exchange event in this project and follows
the numeration of figure 12:

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.

2. A user with a smartphone running the SDL Application’s BackgroundService starts

to "subscribe" for beacon messages.

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

6.4.4 Permissions and requirements

The android manifest is a file that defines the functionality and specifications in an An-
droid application.The manifest provides fundamental information which the system must
have before running the application. The manifest describes the components of the appli-
cation(e.g activities, services etc) and indicate the permissions that an application should
have to access the protected parts of an API[18].

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

7.1 Primary Results

The Smart door lock IoT system can successfully authenticate a user and open the door
when a nearby beacon is present. The user authentication process is handled by the
Azure Active Directory where users can easily be created and managed, figure 13. Both
Authentication API and DoorAPI are successfully deployed to Azure Cloud and can be
accessed by secure HTTPS requests.

Figure 13. Current test members of the Active Directory

The beacon communication between a mobile application and Estimote Beacons is

handled by Google’s API and the actual Bluetooth transmission is using the Eddystone
format. Calls to the Google Nearby API has a high success rate and the beacons are fully
registered in Google Proximity API.

Figure 14. Request traffic to Google APIs, where Nearby API is blue and Proximity API
is green.

Figure 15. The API’s request- and error rate.

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.

7.2.1 LAN misstrust

We have two gaps that consider LAN misstrust in our system structure. The first one is
between the particle microcontroller and the local network resembled by the WiFi network.
The second LAN misstrust gap is between our Android application when it tries to connect
to the the API specifically(Auth API).
Particle has its own Device Protocol Security for handling a secure transmission between
the Photon hardware and the Spark Cloud. According to Particle documentation following
is said about the protocol:

"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.

7.2.2 Environment misstrust

Environment mistrust is always present in the part of the system exposed to the physical
environment, which in this case is the Particle Photon device and the Estimote Beacons.
As mentioned before, the environmental mistrust differs significantly from different IoT
product, depending on the system structure and the physical surrounding of the hardware.
In our situation We can categorize environment misstrust into two branches one physical
and the other being technical. The physical branch includes attacks in the physical medium
For instance close range jamming attacks that leads to harm the microcontroller or beacons
causing them to malfunction. The solution needed don’t have to be technical. In fact, it
can depend more on how and where the user would place the microcontroller and the
beacons.
A simple solution to prevent environmental disruption is to place the product (Beacons
and Photon device) inside the building, that is, behind the actual door the application

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.

7.2.3 Application over-privilege

To prevent application over-privilege the work needs to be directed towards two main goals.
Firstly, the application must be developed in a fashion to prevent other third-party apps
to take advantage of it. But also, the application itself must be built in a way so it does
not do the same to other applications installed on the same smartphone. As multiple
applications can exist and run on the same smartphone, responsibility is required by the
application’s creators. Optimally, all smartphone application should follow the principle
of least privilege.
As prying third-party application can hold the ability to monitor the traffic reaching
our app, it is important that all sensitive data is encrypted. Therefore, a decision was
made to encrypt all data sent and received by the application created in this project. This
implies that third-parties application still can have access to the data, although the data
itself is unreadable without the correct decryption key.
No sensitive data is stored on the smartphone itself due to the project’s system struc-
ture. The user database, authorization, and creation of access tokens are outsourced to the
cloud and denote one of the key solutions for this project. The usage of cloud computing
saves processing power and increases security as well as the overall integrity of the system.
Android lacks a trustworthy system to store sensitive data locally since the data can be
access by a "rooted" device. By moving the authorization process to the cloud no data can
be mined from the application.Adding a cryptography SHA-1 (Secure Hash Algorithm)
fingerprint and connecting it to the API key would restricts the API use only for the au-
thorized app which adds an extra level of security. Furthermore, there is no need to store
a copy of the database on every user’s smartphone, which is generally a bad practice.
Principle of least privilege means the practice of restricting access rights for users to bare
minimum permission needed to perform their task. For forcing the application to follow the
principle of least privilege some simple actions can be taken. Every Android application
comes with a unique Manifest. This manifest provides various important information
about the application, like the application name, activities, and services. The manifest
also provides different permissions needed for the application to function in the desired
manner. These permissions often revolve around communication or permission for access
data from various sensors of the smartphone, eg Gyroscope reading or permission to access
the Internet or Bluetooth. The application needs the user consent to use some permissions,
forcing the awareness of the user for what permissions the application uses. This increases
the transparency of the application as well as decrease the privilege malicious application,

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.

7.2.4 No/Weak Authentication

As mentioned before, authentication is simply the process of detrermining if someone is
eligible by comparing the credentials provided by the user against the ones in the database
contating the authorized users. Authentication is the core of our project in security context.
We have three main parts that are responsible for the authentication process of a user.
These are being introduced in our system as "Auth API", "Door API" and "Azure Active
Directory". The central reason for separating the projects APIs into two unique solutions
was because of the access token flow. The Particle device is controlled by a single access
token that we need to protect. Instead of mixing the user’s unique access token with
the particle’s token the decision of splitting the API was made. One explanation to this
system is that basically, you need an access token to "obtain" the particle access token.
The particle access token can then be nestled and hidden in the door API in a single
instance, rather than stored and copied in multiple smartphone applications.
One reason to use the Azure Active Directory is for its extensive way to handle appli-
cation handshakes. When an application want’s to access a specific API within Azure AD,
an authorized and encrypted handshake is required. This onetime handshake involves the
signing of the public and private key provided by the Azure Cloud. This gives full control
over which resources a specific application can access as well as preventing exterior sources
from accessing the project’s APIs.
When it comes to user authorization and generating access token, the Azure Active
Directory is considered as a well-proven process that many web services rely on.

7.2.5 Implementation Flaws

It is hard to have a rational discussion about the implementation flaws of the product. As
parts of the product are outsourced to other companies, such as Microsoft and Google,
there is a possibility these companies have made implementation mistakes in their own
code, potentially leading to a breach in security. This is one of the potential risks of
outsourcing functionality to other companies.
The iterative test development was mainly motivated to prevent the risk of implemen-
tation flaws. However, this tests can only be applied to a certain extent. The system may
always have some bugs or flaws, however, these tests may prevent the worst-case scenarios.

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.

8.2 Ethics, Sustainability and Benefits

There is always an ethical risk when storing sensitive data, in this case being username
and password, in a database. A breach of the system resulting in leakage of user credential
can lead to gruesome consequences and even legal actions in some existing cases. As user
tends to reuse email addresses and password for different web based services the risk of a
user getting compromised on other services, as a direct consequence, is possible.
When it comes to sustainability, the development of offices and housing has received a
solid boost by IoT. Through connected solutions, more and more of the building’s functions
can now be controlled and optimized based on changing needs. Using IoT technologies at
the office and home, we no longer need to keep an eye on when the coffee machine needs
to be filled or serviced, or when the lighting needs to be replaced. Control of temperature
and ventilation is done automatically. Making energy usage analyzed and streamlined at
all times.
For the Smart door lock, some potential sustainability prospect can be gathered. When
digitalizing a lock, the dependency of physical key objects, such as keys or cards, can
potentially be removed. By using smartphones as keychains, holding multiple keys at a
time, recourses otherwise going to produce keys and cards could be saved. However, it is
hard to believe that this in some way could compensate for the ecological footprints caused

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.

8.4 Future Work

The IoT system that was developed in this thesis focus on the security approach more than
the functionality of the system. However, the main functionality of the system has been
developed where the user is able to access the door using the mobile app. Some of the
functionality that this system need to be further developed is to make it deployable for a
group of users.
Even though the system has a high cohesion within its component, it lacks the ability
to handle some alternative workflows. The system can control the main use-case but can
sometimes be unresponsive because of missing error callbacks. It would be reasonable to
increase the amount of feedback the system gives to both users and administrators, so that
the product appears more trustworthy and is easier to troubleshoot.
An implementation against relay attacks and unintentional locking should also be over-
seen. Prevention of relay attacks could be solved by introducing GPS coordinates as a vital
element. One solution could be to force the mobile application to check if the smartphone
coordinates closely match the coordinates of the deployed beacon. In that way the beacon
will only request to open the door when it is physically present the system and, therefore,
making relay attacks even more difficult.

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.

[7] Indiana University. What is the principle of least privilege? https://kb.iu.edu/d/

amsv, 2017.

[8] A. Perrig et al. In The Tesla Broadcast Authentication Protocol , CryptoByte, vol 5,
pages 2–13.

[9] George Hatzivasilis, Ioannis Papaefstathiou, Konstantinos Fysarakis, and Ioannis

Askoxylakis. Secroute: 2end-to-end secure communications for wireless ad-hoc net-
works. In Computers and Communications (ISCC), 2017 IEEE Symposium on, pages
558–563. IEEE, 2017.

[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.

[13] Torry Harris. Cloud computing services—a comparison. International Journal of

Computer and Information Systems, 3:1–18, 2010.

54
[14] Google inc. Eddystone format. https://developers.google.com/beacons/
eddystone.

[15] Google inc. Eddystone ephemeral identifier. https://developers.google.com/

beacons/eddystone-eid.

[16] Sitepoint tutorials. What is a rest api. https://www.sitepoint.com/

developers-rest-api/.

[17] Tutorialspoint. Android architectural layers. https://www.tutorialspoint.com/

android/android_architecture.htm.

[18] Android developers. Andriod manifest. https://developer.android.com/guide/

topics/manifest/manifest-intro.html.

[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