IOT SECURITY APPLIED ON A SMART DOOR LOCK APPLICATION - KRISTOFFER DJUPSJÖ MASAR ALMOSAWI - DIVA
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
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
74 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
8List 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
910
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
11SHA-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
121 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
13to 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.
142 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.
153. 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
16to 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
17electromagnetic 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.
182.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.
19Figure 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
20are 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.
212.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).
222. 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)
2324
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.
253.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.
264 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
27high 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.
285 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.
299. 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].
305.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
31the 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.
326 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
33You can also read
