IoT Security Applied on a Smart Door Lock Application

(1)

INOM

EXAMENSARBETE TEKNIK,

GRUNDNIVÅ, 15 HP ,

STOCKHOLM SVERIGE 2018

IoT Security Applied on a

Smart Door Lock Application

KRISTOFFER DJUPSJÖ

MASAR ALMOSAWI

KTH

(2)

(3)

Abstract

This thesis describes the development of an IOT application based upon Digitiz-ing a smart door lock for makDigitiz-ing 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.

(4)

(5)

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.

(6)

(7)

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

(10)

(11)

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

(12)

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

(13)

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

(14)

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

(15)

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 syssys-tems 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 figure1. 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.

(16)

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

(17)

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

(18)

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.

(19)

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.

(20)

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

(21)

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.

(22)

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 computcomput-ing 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).

(23)

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)

(24)

(25)

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.

(26)

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 implementaimplementa-tion 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.

(27)

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 beabea-con 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

(28)

high voltage coming from the source. The microcontroller would interpret the signal to

determine whether turning on/off the LED (figure4).

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

(29)

5 System Structure

This chapter describes the final system structure and user base flow, figure5.

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.

(30)

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 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 ideniden-tification 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

(31)

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

(32)

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.

(33)

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

(34)

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 v o i d C r e a t e G o o g l e A p i C l i e n t ( ) { 3 i f ( m G o o g l e A p i C l i e n t == n u l l) {

4 m G o o g l e A p i C l i e n t = new G o o g l e A p i C l i e n t 5 . B u i l d e r ( g e t A p p l i c a t i o n C o n t e x t ( ) ) 6 . addApi ( Nearby . MESSAGES_API) 7 . a d d C o n n e c t i o n C a l l b a c k s (t h i s) 8 . a d d O n C o n n e c t i o n F a i l e d L i s t e n e r (t h i s) 9 . enableAutoManage (t h i s , t h i s) 10 . b u i l d ( ) ; 11 m G o o g l e A p i C l i e n t . 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.

(35)

Figure 7. Basic flow for sending request from Android to particle

1 p u b l i c v o i d l o g i n ( ) {

2 Async . e x e c u 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 O b j e c t c a l l A p i ( P a r t i c l e C l o u d s p a r k C l o u d ) t h r o w s P a r t i c l e C l o u d E x c e p t i o n , I O E x c e p t i o n { 8 s p a r k C l o u d . l o g I n (" xxxxxxxxxxx@gyyyyyy . com", " xxxxxxxxxx ") ; 9 mDevice = s p a r k C l o u d . 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 ( O b j e c 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 , R e m o t e C o n t r o l l e r A c t i v i t y .c l a s s) ; 19 i n t e n t . p u t E x t r a (ARG_DEVICEID, " xxxxxxxxxxxxxxxxxxxxxxx ") ; 20 s t a r t A c t i v i t y ( i n t e n t ) ; 21 }e l s e{ 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 p u b l i c v o i d o n F a i l u r e ( P a r t i c l e C l o u d E x c e p t i o n 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 h a s 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

(36)

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.

(37)

• 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 p u b l i c I H t t p A c t i o n R e s u l t A u t h e n t i c a t e ( C r e d e n t i a l s c r e d e n t i a l s ) 4 { 5 v a r a u t h C o n t e x t = new A u t h e n t i c a t i o n C o n t e x t ( A u t h o r i t y , new TokenCache ( ) ) ; 6 v a r 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 A u t h e n t i c a t i o n R e s u l t r e s u l t ; 8 t r y 9 { 10 r e s u l t = 11 a u t h C o n t e x t . AcquireTokenAsync ( r e s , c l i e n t I d , 12 u s e r P a s s w o r d C r e d e n t i a l ) . R e s u l t ; 13 } 14 c a t c h ( A d a l E x c e p t i o n e e ) 15 { 16 r e t u r n BadRequest ( ) ; 17 } 18 r e t u r n 19 Ok(new A u t h R e s u l t 20 { 21 Token = r e s u l t . AccessToken , 22 ExpiresOn = r e s u l t . ExpiresOn

(38)

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.

(39)

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. Picture9display 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 listing16.

(40)

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 v a r 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 Http RequestM essage r e q u e s t = new HttpRe questMes sage ( ) 8 {

9 R e q u e s t U r i = new U r i ( _baseUrl + _deviceID + " / " + _ f u n c t i o n ) , 10 Content = new FormUrlEncodedContent ( c t ) ,

11 Method = HttpMethod . P o s t 12 } ; 13 v a r 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 r e t u r n r e s p o n s e . T o S t r i n g ( ) ; 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]

IoT Security Applied on a Smart Door Lock Application

IoT Security Applied on a

Smart Door Lock Application

KRISTOFFER DJUPSJÖ

MASAR ALMOSAWI

Contents

List of Figures

Acronyms

1

Introduction

2

Background

3

Methodology

4

Setting Up A Test environment

5

System Structure

6

Software Development