ABSTRACT

This study was conducted to address the critical issue of the poor safety management system in
laboratories, through the design of a smart laboratory management facility based on the Internet of
Things (IoT). In this design, three major safety parameters-fire, temperature and carbon (ii) oxide
(CO) levels were monitored by appropriate sensors, which transmit data to the microcontroller
(Arduino) for interpretation. The Arduino microprocessor processed the data received from the
sensor(s), makes decisions based on the predefined algorithms. Based on the decisions made by the
Arduino, the microprocessor sends instructions to a relay module triggered the necessary actions to be
taken by the output hardware devices-fire extinguisher, air conditioning system and exhaust fan unit.
The temperature monitoring system was designed at an operational range of 18°C to 25°C, the CO
control unit was designed to maintain the CO concentration inside the laboratory at a level not
exceeding 4 parts per million (ppm), as approved by the World Health Organization; while fire
control unit was designed to detect the presence of smoke of naked fire inside the building. In the
event that any of these parameters breach safety thresholds, the smart structure's safety system will
trigger the appropriate responses. The designed structure was built in compliance with international
safety standards. Results obtained through the testing and evaluation of the system revealed that the
smart system had overall performance efficiency of 91% and false output of 9%. The system's failure
rate of 9% can be reduced by employing advanced sensors and adjusting the delay rate. The findings
of this study revealed that IoT and automation can successfully monitor and protect the working
environment inside laboratories. Keywords: Arduino UNO, Automation, C++ Programming,
Environmental control, Health hazards, Sensors and hardware To cite: Odoh FE, Akpomedaye O and
Ekruyota OG (2023). Design and Development of IoT based Smart System for Monitoring Laboratory
Environment. Turkish Journal of Agricultural Engineering

INTRODUCTION

Laboratory is a specialized place equipped with various instruments/apparatus that enhanced research
and developments, analyzed data and contribute immensely to knowledge and development of new
technologies (Junwei et al., 2022; Wang, 2022). Laboratory provides a conducive environment for
methodical investigation and experimentation, enabling researchers to test hypotheses, validate
theories, and make meaningful contributions to their respective fields (Shana and Abulibdeh, 2020).
Laboratories which are integral spaces within colleges and universities play a pivotal role, in the
education and professional development of the students. Apart from practical skills that students learn
in laboratories, they are major source of internal generated revenue to higher institutions, as they carry
out consultancy services for individuals and corporate organizations. Laboratories are hubs for
research and modernization, as they enable individuals/students to conduct experiments,
investigations, and research that will aid their practical knowledge in their respective areas of
specialization (Liboreiro et al., 2022). There are several tasks required for an upkeep of any standard
laboratory. Some of these tasks are environmental monitoring and control, attendance taking,
materials inventory, waste management and other safety precautions. Uguru et al. (2023) reported that
high temperature usually affects the results of most food items during laboratory analysis, hence
temperature should be considered as a serious factor during mechanical and textural evaluation of
most agricultural food products. According to Befekadu et al. (2020), appropriate inventory
management minimized bottleneck laboratory operations, and by ensuring that there are adequate
materials for the smooth running of the laboratory system, by ensuring timely replenishment of
laboratory commodities. Proper inventory management and environmental monitoring greatly
influence the overall efficiency of laboratory operations (Leung et al., 2016; Restiana and Djukri,
2021). Smart system is a new innovation where the system meets remote monitoring needs,
hence reducing the time taken and risks involved in the system operation. Smart systems
enable real-time monitoring of laboratory equipment and processes from a remote location.
The integration of automaton and smart systems into machine operations brings about several
advantages, particularly in the context of remote monitoring and quality control (Ekruyota et
al., 2021; Idama and Ekruyota, 2023). Well-furnished laboratories contribute immensely to
the academic and socio-economic excellence of any institution of learning or research.
Modernized laboratories are often equipped with sensitive apparatus and equipment that
require specific environmental conditions (Timotheou et al., 2023). Many smart systems
come with user-friendly interfaces that make it easy for researchers and technicians to
interact with and control laboratory equipment remotely. Recently there are several
innovations in agricultural productions that evolved from Internet of Things (IoT),
automation, laboratory analysis, and biotechnology (Awad et al., 2022; Dhanaraju et al.,
2022; Rejeb et al., 2022). Research findings from the laboratory have led to the development
plants and animals with anticipated traits, and production of numerous high quality food
items with improved shelf life. This has enhances the state of food security and reduces the
occurrence of malnutrition (Pawlak and Kołodziejczak, 2020; Lenaerts et al., 2019; ODOH et
al., / Turk J. Agr Eng Res (TURKAGER), 2023, 4(2), 263-277 265 Rajeev et al., 2022).
Standard laboratories play a crucial role in supporting and advancing improved agricultural
practices; thus their automation and application of IoT have become paramount interest
(Dhanaraju et al., 2022). IoT is a new engineering innovation which allows hardware to be
remotely activated and deactivated across the internet, as it has the ability to collect, share,
and act on data, creating a network of interconnected systems (Nižetić et al., 2020; Ehsan et
al., 2022). The (IoT) is a complex structure which involves the interconnectivity of various
components (software and hardware) to create a network of interconnected devices.
According to Sisinni et al. (2018), IoT has a lot of influence in the educational, agricultural,
industrial and medical sectors, as it plays a pivot role in monitoring and controlling essential
parameters in the workshop, laboratories and production unit operations. Several smart
systems have been developed and evaluated by numerous researchers, and each system
having its own assets and liabilities (Wenwen et al., 2016; Ma et al., 2017; Zhichuang, 2018;
Li et al., 2020; Zhou, 2022; Zhang and Zhou, 2023). The resources and liabilities of smart
systems are dependent on the specific context, goals, and requirements of the intended
application of the smart structure (Reisinger et al., 2022). The major liabilities of smart
structures are high initial costs of the smart equipment, and non-compatibility of the system
with most obsolete apparatus and machines, though retrofitting package have been developed
to boost the compatibility of older tools and machines with modern advance smart
technologies (Pandiyan et al., 2023). Through numerous smart technologies has been
developed and evaluated (Shazali Dauda and Toro, 2020; Tun and Myint, 2020), research
into the development of hybridized smart university laboratory system is still scanty, mostly
in the area of security and safety. Therefore, the goal of this research is to develop a smart
technology for a modern laboratory of a university that will effectively monitor the
temperature, fire and poisonous gas level. The monitoring of these crucial parameters will
enhance the overall functionality and safety of the laboratory environment.
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 applications
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 requirements 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 system
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)

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 corporate with the cloud to combine and
transfer different co-operations through different communication channels.

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
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
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
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 companies 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 Authentication and
ImplementationFlaws.

2.4.1 LAN Mistrust

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

2.4.2 Environment Mistrust

As IoT-devices are often positioned in the public realm and are exposed to numerous of physical
disturbances and adversaries. When a device has a naive environmental trust it implies weak
resistance against compromisation within physical mediums. An attack of this category can be to
simply destroy the device or its sensors with violence or sending 17 electromagnetic waves to harm
the internal electronics. It can also include different types of techniques to lure the system. For an
example, play a recorded message on a mobile phone in a try to acquire a successive authentication in
voice recognition service. In recent years there have been reported cases of DoS (Denial of Service)
attacks on devices with a naive trust in the local environment. The attacks used close-range jamming
signals to decrease the signal-to-noise ratio and cause the device to malfunction [5].

2.4.3 Application over-privilege

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

2.4.4 No/Weak Authentication

Authentication is the process or action of proving or showing something to be true, genuine,
or valid. An IoT ecosystem often involves multiple different connections to WiFi, Internet,
and sensors via Bluetooth. It is essential that the ecosystem can verify all its connected parts
as well as the API it is connected to, otherwise the system will be an easy target for malicious
attacks. There is also a risk that the system will try to establish and transmit sensitive data to
devices outside the proximity of the product. Weak authentication is often a problem in
Bluetooth communication as devices either provide no or weak PINcode 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 .
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 authentication
protocol . 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. Access control is another
solution that is discussed but not implemented yet. Access control 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.
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 .
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
Authentication 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.
 Figure2. Naïve 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 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 authorized
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".
 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 product.
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.
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 development. 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 software 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 computing 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).
2. Platform as a Service(PaaS): a layer of software or development environment is
encapsulated & 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 capabilities
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)

2. Materials and Method

2.1. System Architecture and Design

The classic Ethernet and/or a Wi-Fi local network are usually enough for a working
Toggle setup. The different hardware used in the system includes Raspberry Pi 3 or 4 boards
(any model), ESP 8266 Wi-Fi modules, and smart devices. The Raspberry Pi version used for
this project is Raspberry Pi 4, due to the improvements brought, as compared to previous
versions. For example, Raspberry Pi 1 and 2 do not have Bluetooth (it is needed for
controlling the thermostats). An important feature of the Raspberry Pi is the row of general-
purpose input/output (GPIO) pins. A 40-pin GPIO header is found on all current Raspberry Pi
boards [44]. The three roles of a Raspberry Pi board in a qToggle setup are the following: the
board could act as a qToggle device when it is equipped with peripherals (sensors or relay
boards), it could also act as a master hub for other devices, and, finally, it could help install
the ESP firmware on some devices, when running Tuya Convert OS (Tuya is a Chinese smart
devices platform that offers cloud services for ESP8266/ESP8285-based devices). Tuya
Convert OS helps replace this proprietary Tuya firmware with a custom firmware, without
disassembling the device. An important fact is that it works only for Tuya-based devices. In
fact, Tuya Convert OS is a customized Raspbian OS image that runs Tuya Convert with a
friendly user interface.
The main part of the home automation system based on IoT is the microcontroller. The
ESP 8266 Wi-Fi module represents a set of efficient highly integrated wireless Systems on
Chip (SoCs), which provides a complete and standalone Wi-Fi network solution. The
ESP8266EX version is one of the most integrated Wi-Fi chips in the industry. In addition to
its Wi-Fi functionalities, ESP8266EX integrates an enhanced version of L106 Diamond series
32-bit processor from Tensilica (company based in Silicon Valley, in the semiconductor
domain), with on-chip SRAM. ESP8266EX has seventeen GPIO pins, which can be assigned
to various functions by programming the appropriate registers, two power pins, one ground
pin, reset pin, and two clock pins. The devices used by qToggle are usually sensors or
actuators with an upstream network connection. Keeping the device firmware updated is
probably one of the most essential tasks, and it is often neglected when dealing with a large
number of devices. qToggle facilitates this task by allowing updates of the firmware very
simply for devices of different types and models. The qToggle API is an intuitive HTTP API
that enables remote controlling of basic hardware ports, such as GPIOs or analog-to-digital
converters (ADC).
The idea behind qToggle is to control programmable systems having a TCP/IP stack via
simple HTTP requests.
For example, these systems can be single-board computers or TCP/IP-enabled
microcontrollers. API functions are grouped into the following categories:
 Device management—general status and configuration of the device;
 Port management—port information and configuration;
 Port values—reading and writing values from and to ports;
 Notifications—event notifications;
 Reverse API calls—API calls via reverse HTTP requests.
API specifications may seem quite complex, offering a wide range of functionalities and
use cases. However, most of them are optional, and only a small set of functions are
mandatory for a qToggle implementation.
The qToggle ecosystem is composed of a qToggleServer, qToggleOS, espQToggle, add-
ons, and other tools and packages that are specific to certain setups and use cases. The main
component is qToggleServer, which is written in Python. It acts as a hub and provides the
user-friendly web app. qToggleOS is an operating system (OS) ready to be used with
Raspberry Pi boards and runs qToggleServer. espQToggle is a custom firmware for
ESP8266/ESP8285 devices and implements the qToggle API. Finally, add-ons are optional
pieces of software that enhance the functionality of qToggleServer. A device used by
qToggle will describe itself, indicating its configuration, its supported optional
functionalities, and what ports it exposes. Each port, in its turn, will describe itself, indicating
its identifier, type, configuration, and so on. By combining master–slave relationships
between simple devices and hubs in a network, a complex tree topology is obtained. Thus, a
large number of smart devices can be easily managed, as shown in Figure 2. The type of
communication in Figure 2 is Wi-fi or Ethernet. Consumers could operate at any level in the
hierarchy, thus limiting the access inside the network to any desired subtree.
 Figure 2. The qToggle topology.
In a real-world setup, it is difficult to individually manage many devices. Therefore, a
hub will allow a centralized administration of devices used by qToggle. Hubs act as
consumers when communicating to other devices, but they also expose an API interface that
allows other consumers to see them as devices. This allows for the creation of complex
hierarchies of devices and hubs that are in a master–slave relationship. With qToggle, a
device may act as a master for other slave devices. The master controls slave devices and
allows accessing them through its own API functions. In the same way, a slave device can act
as a master for other devices. Thus, complex chained master–slave configurations can be
obtained. Special API functions are supported by the master for listing, adding, and removing
slaves. Slave devices are identified on the master by their names, but the master must be
prepared for a slave’s name to change at any time.
qToggle implements three roles that dictate the access level: the administrator role,
which has the absolute power over a device, being able to view and modify the configuration;
the normal role, which has no access the configuration but can read from/write to ports, and
the view-only role that can only read the port’s values. To facilitate automation, qToggle
allows adding rules that dictate port values, based on various conditions. This means that a
port can be taught to use an expression based on other ports and functions in a way that
resembles spreadsheet formulas. Expressions can be set at a device level or at a hub level.
Expressions on a device are very fast, but they can only depend on ports present on the
device. When setting an expression at a hub level, the ports of any device that is known by
the hub can be included. This will effectively implement relations between different devices.
If consumers need to be notified about events that take place on the device, for example port
value changes, qToggle offers three notification methods: listening for events using long
HTTP requests (long polling), webhooks, and polling (the least efficient, but easiest to be
implemented). qToggle setups are usually deployed in private networks, where devices
cannot be directly accessed from the Internet. The solutions often depend on port forwarding,
where public IPs are available. If port forwarding is not wanted/impossible, the devices can
be set to open a connection to an external public server and to wait for API requests. This
mechanism is called reverse HTTP and allows making HTTP requests to a device inside a
private network without forwarding any port.
From a developer point of view, qToggle offers add-ons that are an easy and convenient
way of packaging optional functionalities, which are usually tied to a specific device or
service. Add-ons can be published or be kept private, depending on the developer’s needs and
licensing requirements. The entire source code is completely opensource [45], so one can
easily understand how it works, may propose changes or may even join the team. In addition,
we provide documentation on using and further developing qToggle for new devices or use
cases.
Regarding the security, qToggle uses a series of best practices that are often found in
nowadays web-based applications. HTTPS is employed for when a client from the outside
(the Internet) talks to the hub. It ensures encryption, authenticity of the hub, and integrity of
the HTTP messages. Plain HTTP is used only locally, inside the premises, between the hub
and its controlled devices. A TLS certificate is used in conjunction with HTTPS to ensure the
security goals mentioned above; Let’s Encrypt is used to generate and renew the TLS
certificates. This process is done automatically on the hub, upon certificate expiry. Remote
(administrative) access on the hub is done via SSH. The SSH protocol uses ECDSA (or
similar) private/public key pairs for authentication and encryption. Alternatively, the
administrator password defined on the hub may be used to log in remotely with username and
password.
The API defines three roles that dictate the permissions of an API request: administrator,
normal user, and view-only user. API requests use the JSON Web Token (JWT) defined by
RFC 7519 to supply authentication data. A shared secret (called password) ensures the
authenticity of the caller. The secret is hashed with a salt before used to sign the JWT token
to prevent compromising the original password. Reply attacks are prevented by using the
current timestamp as a nonce included in the JWT.
Alternatively, we could have used HTTP Basic Authentication, HTTP Digest
Authentication, or a cookie-based session management with a conventional login form. Basic
Authentication is insecure when transmitted over unencrypted channels, while Digest
Authentication is unnecessarily complicated and requires exchanging multiple messages. The
cookie/session-based method is prone to session stealing attacks and may also be insecure on
unencrypted channels.
The embedded Over-the-Air (OTA) mechanism (firmware update) ensures that the hub
as well as its attached devices always run the latest available version, thus allowing us to
quickly bring security patches in case a vulnerability is discovered.

2.2. Configuring the Web Application

Toggle Server provides a user-friendly interface, named frontend, which comes in the
form of a progressive web application (PWA). It is designed to be used on smartphones,
tablets, but also on laptops/desktop machines. Firstly, the application should be installed and,
being a PWA, it should be added to the home screen. After installation, the qToggle app will
be found in the applications list of the device, and it can be uninstalled whenever the user
wants to. When the user logs in for the first time (see Figure 3a), an admin with an empty
password should be used. However, for security reasons, it is highly recommended to set a
password in the Settings page of the app.

The dashboard is the section where users will spend most of the time when using
qToggleServer. Here, they can create panels and groups of panels, as shown in Figure 4. In
the panel edit mode, the user can perform various tasks, for example add, move around,
remove, resize, or configure widgets. Widgets usually require selecting one or more ports.
Ports values will be displayed and/or changed by the widget upon interaction.

An example is given in Figure 5. The ports section is only accessible to administrators.

In this section, the user may add, remove, and configure ports (see Figure 6). If users have
slave devices management enabled in qtoggleserver.conf (by default they are enabled), the
first thing they will have to do is to select the device whose ports will be edited. The first
device in the list represents the hub (the master device) itself. An important fact is that only
administrators can add, remove, and configure slave devices (see Figure 7).

qToggle app is linked with the qToggleServer package. This means that users will get an
app update whenever they update their qToggleServer installation. Since qToggle is a web
app, the update process is done automatically by the browser, when the user reopens or
refreshes the app. The user can either close it and reopen it, or he/she can use the pull-to-
refresh function to make sure the app is up to date. The code and documentation for qToggle
can be found on Github
Block Diagram:

The system software

The Arduino Compiler (Integrated Development Environment-“IDE”), Blynk application for
Android, and MATLAB were the software packages/platforms used for developing the
system. The Arduino Compiler IDE is a powerful software platform that provides a user-
friendly interface for programming Arduino microcontroller, and it is compatible with C++
programming language. Blynk Application for Android enables the development of more
flexible Internet of Things (IoT) applications. Blynk Application has a strong potential of
creating a graphical user interface (GUI) for IoT structures on mobile device. The MATLAB
software was used to complement the capabilities of the Arduino in this smart laboratory
facility. Remarkably, since Arduino which is compatible with C++ programming language
was selected as the microprocessor, the C++ programming language was chosen as the
programming language of the smart system.
The system hardware
Microcontroller
An Arduino UNO R3 (model-ATmega328P) as shown in Figure 1 was used as
microcontroller for the design of the smart facility. The Arduino UNO have these
specifications: voltage rating-6 V to 20 V, direct current-20 mA, main processor clock speed-
16 MHZ, Memory-2KB SRAM and 32KB FLASH-, and operating voltage of 5 V was used
as microcontroller for the design of the smart facility.

Figure 1. An Arduino microprocessor.

MQ-2 Gas Sensor

The MQ-2 gas sensor is a popular choice for detecting various gases, including carbon
monoxide (CO) and smoke. It offers a reliable and cost-effective solution for monitoring air
quality and ensuring safety in indoor environments such as laboratories, homes, and offices.
This section provides an elaboration on the specifications, operating principles, and
applications of the MQ-2 gas sensor.

1. Specifications

The MQ-2 gas sensor is designed to operate with a voltage of 5V DC, making it compatible
with standard microcontroller platforms such as Arduino. Its heating resistance is rated at
33Ω, with a power consumption of 800mW. The sensing resistance of the MQ-2 sensor
ranges from 10 kΩ to 60 kΩ, providing a wide detection range for various gases. These
specifications make the MQ-2 sensor suitable for integration into diverse monitoring systems.

2. Operating Principle
The MQ-2 gas sensor utilizes a semiconductor-based gas sensing element to detect target
gases in the surrounding environment. When exposed to a specific gas, the sensor's resistance
changes, leading to variations in the output voltage. This change in voltage is proportional to
the concentration of the detected gas. The MQ-2 sensor relies on the principle of chemical
reactions between the target gas and the sensing material within the sensor. By measuring the
resulting resistance, the sensor can accurately determine the presence and concentration of
gases such as CO and smoke.

3. Connection to Arduino Microcontroller

The MQ-2 gas sensor can be easily interfaced with an Arduino microcontroller for reading
and processing sensor data. It typically requires analog input pins on the Arduino board to
measure the sensor's output voltage. By applying a voltage divider circuit, the varying
resistance of the sensor can be converted into a proportional voltage signal that can be read
by the microcontroller. Arduino's analog-to-digital converter (ADC) capabilities enable
accurate measurement and interpretation of the sensor's output.

4. Applications

The MQ-2 gas sensor finds numerous applications in gas detection and air quality monitoring
systems. In laboratory settings, it can be used to detect the presence of CO and smoke,
alerting users to potential hazards such as gas leaks or fire outbreaks. In residential
environments, the sensor can be integrated into home automation systems to enhance safety
and security. Other applications include industrial gas detection, vehicle emissions
monitoring, and environmental pollution control.

DHT11 sensor
The DHT11 sensor is a widely used component for monitoring temperature and humidity
levels in various applications, ranging from home automation to industrial processes. This
section provides an elaboration on the specifications, operating principles, and applications of
the DHT11 sensor.

1. Specifications

The DHT11 sensor is designed specifically for measuring temperature and humidity with a
resolution of 1°C and 1% humidity, respectively. It operates with an operating current of 2.5
mA and requires a voltage of 5V DC for proper functioning. These specifications make the
DHT11 sensor suitable for integration into a wide range of electronic systems and
microcontroller-based projects.

2. Operating Principle

The DHT11 sensor utilizes a thermistor to measure temperature and a humidity sensor to
measure relative humidity. The thermistor changes its resistance with variations in
temperature, while the humidity sensor detects changes in humidity levels through a
capacitive sensing element. By monitoring the electrical characteristics of these sensors, the
DHT11 sensor can accurately determine both temperature and humidity with the specified
resolution.

3. Connection and Interfacing

The DHT11 sensor can be easily connected to microcontrollers such as Arduino or Raspberry
Pi using digital input/output pins. It communicates with the microcontroller through a single-
wire digital interface, simplifying the wiring and integration process. The sensor provides
digital output signals containing temperature and humidity data, which can be read and
processed by the microcontroller for further analysis or display.

4. Applications

The DHT11 sensor finds a wide range of applications in temperature and humidity
monitoring systems. In indoor environments, it is commonly used in climate control systems,
weather stations, and HVAC (heating, ventilation, and air conditioning) systems to maintain
comfortable and healthy living conditions. In industrial settings, the sensor is employed for
environmental monitoring, storage facilities, and process control to ensure optimal operating
conditions and product quality.

5. Limitations

While the DHT11 sensor offers a cost-effective solution for basic temperature and humidity
monitoring, it has certain limitations. Its accuracy and reliability may be affected by factors
such as variations in supply voltage, ambient temperature, and sensor aging. Additionally, the
sensor's response time may be relatively slow compared to more advanced sensors with
higher resolutions.
Arduino Buzzer
The integration of a buzzer into the smart system design adds an auditory alerting
mechanism, enhancing its functionality and usability. This section provides an elaboration on
the specifications, operating principles, and applications of the buzzer used with Arduino.

1. Specifications

The buzzer selected for the smart system design is characterized by its maximum sound
output level of approximately 88 decibels (dB), making it suitable for generating audible
alerts and notifications in indoor environments. It operates within a wide voltage range, from
3V to 24V, providing flexibility in its compatibility with various power sources and
microcontroller platforms.

2. Operating Principle

The buzzer operates on the principle of electromechanical vibration, converting electrical

signals into sound waves. It consists of a piezoelectric element or an electromagnetic coil
attached to a diaphragm. When an electrical signal is applied to the buzzer, it causes the
piezoelectric element to deform or the electromagnetic coil to generate a magnetic field,
resulting in the vibration of the diaphragm and the emission of sound waves.

3. Connection and Interfacing with Arduino

The buzzer can be easily interfaced with an Arduino microcontroller using digital output pins.
By applying a digital high (HIGH) signal to the buzzer pin, the microcontroller activates the
buzzer, causing it to emit sound. Conversely, applying a digital low (LOW) signal deactivates
the buzzer, silencing the sound output. This simple interfacing mechanism allows for
seamless integration of the buzzer into the smart system design, enabling auditory feedback
based on predefined conditions or events.

4. Applications
The buzzer's versatility and reliability make it suitable for a wide range of applications in
smart systems and electronic projects. In the context of the smart system design, the buzzer
serves as an effective alerting mechanism for notifying users of important events or
conditions, such as unauthorized access attempts, detected gas leaks, or abnormal temperature
levels. Beyond the smart system, buzzers are commonly used in alarm systems, timers,
notification devices, and interactive games, among other applications.

Wi-Fi module
The wireless router supports 2.4 GHz Wi-Fi with a transmission rate of 300 Mbps. It 3 ports,
with each port supporting network speeds of approximately 100 Mbps and, CPU frequency of
650 MHZ.

Relay module

Relay modules play a crucial role in the functionality and control of the system, enabling the
integration of high-power output devices with low-power microprocessors. This section
provides an elaboration on the functions, working principles, and applications of relay
modules within the system.

1. Functions

Relay modules are specifically designed to interface between low-power control devices,
such as microcontrollers, and high-power output devices, such as motors, heaters, lights, and
appliances. Their primary function is to act as a switch, allowing the microcontroller to
control the ON/OFF state of the connected output device. By receiving instructions from the
microcontroller, the relay module can either energize or de-energize its internal relay, thereby
activating or deactivating the connected load.

2. Working Principle

The working principle of a relay module is based on electromagnetic induction. It consists of

an electromechanical relay, which comprises a coil and a set of contacts. When a voltage is
applied to the coil, it generates a magnetic field, causing the contacts to either close or open,
depending on the relay type. In a normally open (NO) relay configuration, the contacts are
open when the relay is not energized, allowing current to flow through the load when the
relay is activated. Conversely, in a normally closed (NC) relay configuration, the contacts are
closed by default, and they open when the relay is energized, interrupting the current flow to
the load.
3. Application

Relay modules find widespread applications in various industries and electronic systems
where there is a need to control high-power devices using low-power control signals. In the
context of the system development, relay modules are utilized to interface with actuators such
as solenoid locks, motors, and heaters. For example, in a smart door locking system, the relay
module can be used to control the locking and unlocking mechanism based on signals
received from the microcontroller. Similarly, in home automation systems, relay modules
enable the control of lighting, heating, and cooling systems, enhancing energy efficiency and
user convenience.

4. Advantages

Isolation: Relay modules provide electrical isolation between the low-power control circuit
and the high-power output device, protecting the control hardware from voltage spikes and
electrical noise.

Versatility: Relay modules are available in various configurations, including single-channel,

multi-channel, normally open, normally closed, and latching relays, allowing for flexibility in
design and application.

Reliability: Electromechanical relays have a proven track record of reliability and durability,
making them suitable for long-term operation in demanding environments.

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 implementing
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.
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.
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.
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 implementation 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.
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.

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.

Choice of Bluetooth Beacons

A Bluetooth beacon has a relatively simple hardware structure. The purpose of the beacon 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 configuration and well-documented SDK for multiple
different platforms. The beacons support third-party Bluetooth transmissions protocols,
granting more options to developers.

Test Environment/Experimental Design

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

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.

Test of MCU
The Photon MCU was used to test a basic functionality within the design. A test program was
written to control a LED on the microcontroller itself. Thereafter, a test environment was set
up on a breadboard to control an external LED using a relay that controls the 27 high voltage
coming from the source. The microcontroller would interpret the signal to determine whether
turning on/off the LED (figure 4).
Figure 4. Schematic of the working relay. The lock is represented as a LED in the experimental
design.

System Structure

This chapter describes the final system structure and user base flow, figure
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.
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.

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 transmissions protocols. Both Apple and Google offers their own widely popular
Beacon transmission technology, this project will rely on Google’s open format called
Eddystone.

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 namespaceID
and and a specif InstanceID.
2. Eddystone-EID works similar to UID but pseudo-randomly generates a new identificaton
with a developer set lifetime. The 8-byte identification string is also AESencrypted.
3. Eddystone-TLM sends telemetric data from the beacons sensors, such as temperature,
battery status or atmospheric pressure.
4. Eddystone-URL sends a given URL to its environment.
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
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.

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 systems using HTTP to obtain data and generate operations on these data in all
possible formats (e.g XML and JSON)

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

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.

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

An access token is an object that is implemented in the security context when working authentication.
It is considered a credential that can be used by the client to access a specific API. it is considered as a
unique string containing letters and numbers where this string is passed with every API call. The
information in a token includes the identity of 31 the user associated with the process being
performed(e.g Authentication). The purpose of the access token is to notify the API that the
beneficiary of this token has been authorized to access the API and perform a specific operation.
Result and Analysis
This chapter goes through the primary result and objectives achieved by this thesis. The goal
was to create a functioning IoT product that takes the security aspects in regard. A test was
applied on every subsystem during the development until reaching the last milestone where
we had a functioning product
Primary Results
The Smart door lock IoT system can successfully authenticate a user and open the door when
a nearby beacon is present. The user authentication process is handled by the Azure Active
Directory where users can easily be created and managed, figure 13. Both Authentication API
and DoorAPI are successfully deployed to Azure Cloud and can be accessed by secure
HTTPS requests. The beacon communication between a mobile application and Estimote
Beacons is handled by Google’s API and the actual Bluetooth transmission is using the
Eddystone format. Calls to the Google Nearby API has a high success rate and the beacons
are fully registered in Google Proximity API.

Discussion
This subchapter presents the security challenges and how we managed to solve the security
gaps from IoT system perspective.
LAN mistrust
We have two gaps that consider LAN misstrust in our system structure. The first one is
between the particle microcontroller and the local network resembled by the WiFi network.
The second LAN misstrust gap is between our Android application when it tries to connect to
the the API specifically(Auth API). Particle has its own Device Protocol Security for
handling a secure transmission between the Photon hardware and the Spark Cloud. According
to Particle documentation following is said about the protocol: "Communications between the
Particle Cloud and each Particle device are encrypted by default. Every device ships with a
unique device-specific RSA or Elliptic Curve key-pair, and has a pinned Cloud public key.
The device public key is typically pinned in the cloud during manufacturing, but can be
updated later by an authorized user. Strong unique keys and bidirectional pinning help
prevent man-in-the-middle attacks against devices and data." [19] As said, the encryption
keys used for communication is generated and pinned in the manufacturing process of the
Particle product and extends from the scope of WiFi. Meaning that no key exchange between
the Particle Spark cloud and Photon hardware design will go through the wireless network.
Making all data transmission through WiFi undecryptable for other nodes in the network.
There is no concrete way to always make sure that the LAN connection completely secure as
smartphone users are admissible to use whatever network they want to. This is problematic
when transmissions include sensitive data (such as user credentials and access tokens). A
better approach than securing the LAN for the smartphone is the secure the transmission itself
by encryption. If the transmission is encrypted with HTTPS the trust is moved from the LAN
to the certificates provided by the requested server. The trusted authority, in this case, is then
the Azure Cloud. Moving the trust from WLAN to the Azure cloud acquires a static, more
secure solution for the product. Due to particles security protocol and the HTTPS protocol
used to send sensitive data, we are assuring that no one can eavesdrop on the data
transmission and therefore both gaps being exposed to LAN misstrust are secured.
Environment mistrust
Environment mistrust is always present in the part of the system exposed to the physical
environment, which in this case is the Particle Photon device and the Estimote Beacons. As
mentioned before, the environmental mistrust differs significantly from different IoT product,
depending on the system structure and the physical surrounding of the hardware. In our
situation We can categorize environment misstrust into two branches one physical and the
other being technical. The physical branch includes attacks in the physical medium For
instance close range jamming attacks that leads to harm the microcontroller or beacons
causing them to malfunction. The solution needed don’t have to be technical. In fact, it can
depend more on how and where the user would place the microcontroller and the beacons. A
simple solution to prevent environmental disruption is to place the product (Beacons and
Photon device) inside the building, that is, behind the actual door the application 47 is
controlling. In that way, only authorized user has access to the nearby environment of the
hardware, preventing the risk of unwanted attention from other humans with harmful
intentions. As the unlocking process relies on wireless communication various of layout
options exists. A simple rule to follow is to hide the beacon and device as much as possible,
far from the reach of physical intervention. The other technical branch revolves around on the
communication with nearby devices. How can the device establish if a received nearby
Bluetooth transmission comes from an authorized device? If the device always trusts the
source of a transmission, a malicious device could impersonate a trusted source in a try to
prompt an unwanted behavior from the door lock device. To prevent this from happening full
control of device authorization is needed. This can only be succeeded with reliable encryption
and device authentication management. This is why the Google API was a relevant approach
for this product. Due to the Eddystone-EID protocol, we can filter out all other beacon and
Bluetooth transmissions polluting the environment. The one-time key exchange between
beacon and smartphone happens in another medium, so no key exchange will take place in
the nearby environment, making the system thoroughly secure.
Application over-privilege
To prevent application over-privilege the work needs to be directed towards two main goals.
Firstly, the application must be developed in a fashion to prevent other third-party apps to
take advantage of it. But also, the application itself must be built in a way so it does not do
the same to other applications installed on the same smartphone. As multiple applications can
exist and run on the same smartphone, responsibility is required by the application’s creators.
Optimally, all smartphone application should follow the principle of least privilege. As
prying third-party application can hold the ability to monitor the traffic reaching our app, it is
important that all sensitive data is encrypted. Therefore, a decision was made to encrypt all
data sent and received by the application created in this project. This implies that third-parties
application still can have access to the data, although the data itself is unreadable without the
correct decryption key. No sensitive data is stored on the smartphone itself due to the
project’s system structure. The user database, authorization, and creation of access tokens are
outsourced to the cloud and denote one of the key solutions for this project. The usage of
cloud computing saves processing power and increases security as well as the overall
integrity of the system. Android lacks a trustworthy system to store sensitive data locally
since the data can be access by a "rooted" device. By moving the authorization process to the
cloud no data can be mined from the application.Adding a cryptography SHA-1 (Secure Hash
Algorithm) fingerprint and connecting it to the API key would restricts the API use only for
the authorized app which adds an extra level of security. Furthermore, there is no need to
store a copy of the database on every user’s smartphone, which is generally a bad practice.
Principle of least privilege means the practice of restricting access rights for users to bare
minimum permission needed to perform their task. For forcing the application to follow the
principle of least privilege some simple actions can be taken. Every Android application
comes with a unique Manifest. This manifest provides various important information about
the application, like the application name, activities, and services. The manifest also provides
different permissions needed for the application to function in the desired manner. These
permissions often revolve around communication or permission for access data from various
sensors of the smartphone, eg Gyroscope reading or permission to access the Internet or
Bluetooth. The application needs the user consent to use some permissions, forcing the
awareness of the user for what permissions the application uses. This increases the
transparency of the application as well as decrease the privilege malicious application, 48 as
the user hopefully reflects why an application would ask for irrelevant permissions. In the
SDL Application user permissions for Bluetooth low energy and Internet are used. A small
extra note can be made about the usage of the service component. As discussed above,
multiple applications need to work together and share the same battery, processor, and
memory in the smartphone. By implementing the beacon listening on the service we take the
responsibility by saving a significant amount smartphone’s resources. 7.2.4 No/Weak
Authentication As mentioned before, authentication is simply the process of detrermining if
someone is eligible by comparing the credentials provided by the user against the ones in the
database contating the authorized users. Authentication is the core of our project in security
context. We have three main parts that are responsible for the authentication process of a
user. These are being introduced in our system as "Auth API", "Door API" and "Azure
Active Directory". The central reason for separating the projects APIs into two unique
solutions was because of the access token flow. The Particle device is controlled by a single
access token that we need to protect. Instead of mixing the user’s unique access token with
the particle’s token the decision of splitting the API was made. One explanation to this
system is that basically, you need an access token to "obtain" the particle access token. The
particle access token can then be nestled and hidden in the door API in a single instance,
rather than stored and copied in multiple smartphone applications. One reason to use the
Azure Active Directory is for its extensive way to handle application handshakes. When an
application want’s to access a specific API within Azure AD, an authorized and encrypted
handshake is required. This onetime handshake involves the signing of the public and private
key provided by the Azure Cloud. This gives full control over which resources a specific
application can access as well as preventing exterior sources from accessing the project’s
APIs. When it comes to user authorization and generating access token, the Azure Active
Directory is considered as a well-proven process that many web services rely on.
Implementation Flaws
It is hard to have a rational discussion about the implementation flaws of the product. As
parts of the product are outsourced to other companies, such as Microsoft and Google, there
is a possibility these companies have made implementation mistakes in their own code,
potentially leading to a breach in security. This is one of the potential risks of outsourcing
functionality to other companies. The iterative test development was mainly motivated to
prevent the risk of implementation flaws. However, this tests can only be applied to a certain
extent. The system may always have some bugs or flaws, however, these tests may prevent
the worst-case scenarios.

Conclusion and Future Work

This chapter concludes the work done in this thesis.

Conclusion
Internet of things is one of the hugest revolutions in the technological field. It is the concept
that describes the idea of connecting everyday physical objects to the internet trying to
digitalise it. As we mentioned before it is expected to have more than 18 billion devices
connected to the internet by 2022. The risks we are facing are the security aspects when
connecting these devices and applications to the internet. The problem is that each of these
devices and applications have it is own security gaps that should be considered making it
hard to standardize the the security aspects in all the devices. Understanding the basics
principles of IoT architectures is a must when developing a product that is going to interact
with the nearby environment. The product of this thesis is a fully functional smart door
application. This system follows the typical IoT infrastructure explained in chapter
Where the smartphone application works as the user-centric interaction point. The developed
APIs can be seen as the "delegate"-part and the Bluetooth beacons can be interpreted as the
"sensors". It was important that the product followed this typical infrastructure as we wanted
our prototype to act and behave like a common IoT-product. The security implementation of
the product gave an overall, more robust result. By following these 5 major security fields
resulted in a more reliable product where, we developers, had to think outside the box to
fulfill the demands of each field. However, the product lacks some security concerning the
functionality of the product. Due to "automatic unlocking", there is no comprehensive
prevention against "unwanted unlocking" and "Relay attacks". However, an implementation
of this problem area is discussed later in this chapter under future work. We haven’t found
any other products on the market that is similar to our solution. The Bluetooth Beacon
solution of this project seems to be unique in the consumer market for the smart door lock. As
the Google Beacon API and Google Messages API is a fairly new technology, it is possible it
will exist in the nearby future.

Ethics, Sustainability and Benefits

There is always an ethical risk when storing sensitive data, in this case being username and
password, in a database. A breach of the system resulting in leakage of user credential can
lead to gruesome consequences and even legal actions in some existing cases. As user tends
to reuse email addresses and password for different web based services the risk of a user
getting compromised on other services, as a direct consequence, is possible. When it comes
to sustainability, the development of offices and housing has received a solid boost by IoT.
Through connected solutions, more and more of the building’s functions can now be
controlled and optimized based on changing needs. Using IoT technologies at the office and
home, we no longer need to keep an eye on when the coffee machine needs to be filled or
serviced, or when the lighting needs to be replaced. Control of temperature and ventilation is
done automatically. Making energy usage analyzed and streamlined at all times. For the
Smart door lock, some potential sustainability prospect can be gathered. When digitalizing a
lock, the dependency of physical key objects, such as keys or cards, can potentially be
removed. By using smartphones as keychains, holding multiple keys at a time, recourses
otherwise going to produce keys and cards could be saved. However, it is hard to believe that
this in some way could compensate for the ecological footprints caused 51 by the production
of smartphones. The SDL-product assumes that users already own a smartphone and the
sustainability of smartphones is, therefore, outside the scope of this project. This product
takes responsibility for preventing electromagnetic pollution and disturbances by only using
industry standard transmission protocols and EMC-marked hardware. This product must have
a high electromagnetic compatibility as the product could be deployed in heavily polluted
areas, such as offices located in densely populated areas. This has not been researched
thoroughly but the developed prototype shows no signs of a lacking electromagnetic
compatibility. By moving as much data processing to the cloud as possible, the general power
consumption of the product is decreased. Instead of relying on the batteries of the user’s
smartphone, the power of the cloud is used, saving energy recourses as well as lower the wear
of the smartphone batteries.

Risks
There is a substantial risk involved with developing an electronic door lock. Locks are a
product of safety and rely on a great trust between product and user. The owner of the lock
must feel completely confident that the lock is secure. This trust is hard to acquire and very
easy to lose. A responsibility lies also on the owner and administrator of the smart door lock.
Careless usage of the product can compromise the safety of the people inside the building and
also lead to direct damage the building’s property. This prototype could also very well
malfunction, either by an external or internal, fault of the system. This fault could, for
example, be a loss of internet connection or electricity. In that case, some kind of backup
functionality should be considered. This backup could imply a still functional traditional lock
installed on the door, or expanding the functionality of the prototype, making it still
functional and secure during a power/internet outage. In extreme cases, such as fire
emergencies and other relevant scenarios it is of utmost importance that the door lock
behaves in a predictable way. The smart door lock, therefore, need to possess the ability to
override its normal behavior, allowing people to use the door freely in such specific cases.

Future Work
The IoT system that was developed in this thesis focus on the security approach more than
the functionality of the system. However, the main functionality of the system has been
developed where the user is able to access the door using the mobile app. Some of the
functionality that this system need to be further developed is to make it deployable for a
group of users. Even though the system has a high cohesion within its component, it lacks the
ability to handle some alternative workflows. The system can control the main use-case but
can sometimes be unresponsive because of missing error callbacks. It would be reasonable to
increase the amount of feedback the system gives to both users and administrators, so that the
product appears more trustworthy and is easier to troubleshoot. An implementation against
relay attacks and unintentional locking should also be overseen. Prevention of relay attacks
could be solved by introducing GPS coordinates as a vital element. One solution could be to
force the mobile application to check if the smartphone coordinates closely match the
coordinates of the deployed beacon. In that way the beacon will only request to open the door
when it is physically present the system and, therefore, making relay attacks even more
difficult. 52 Unintentional unlocking could be solved with a similar solution using GPS
technology. You could implement the system in a way that the user needs to leave the office
with a certain distance before the application asks for unlocking again, preventing the risk of
the application resending requests when the user is located inside the office. Another simpler
approach could be to install a simple button next to the door, prompting the door to open if
both a user’s smartphone is nearby and the button is pressed. However, this solution is not
ideal as a non-user could wait outside the door until a person inside the building walks

References
[1] Ericsson AB. Iot security, white paper. https://www.ericsson.com/assets/
local/publications/white-papers/wp-iot-security-february-2017.pdf. Accessed: 2017.
[2] Jie Lin, Wei Yu, Nan Zhang, Xinyu Yang, Hanlin Zhang, and Wei Zhao. A survey on
internet of things: Architecture, enabling technologies, security and privacy, and applications.
Internet of Things Journal, IEEE, 4(5):1125–1142, October 2017.
[3] Kewei Sha, Ranadheer Errabelly, Wei Wei, T Andrew Yang, and Zhiwei Wang. Edgesec:
Design of an edge layer security service to enhance iot security. In Fog and Edge Computing
(ICFEC), 2017 IEEE 1st International Conference on, pages 81–88. IEEE, 2017.
[4] Grant Ho, Derek Leung, Pratyush Mishra, Ashkan Hosseini, Dawn Song, and David
Wagner. Smart locks: Lessons for securing commodity internet of things devices. Master’s
thesis, University of California, Berkeley, 2016.
[5] Nan Zhang, Soteris Demetriou, Xianghang Mi, Wenrui Diao, Kan Yuan, Peiyuan Zong,
Feng Qian, XiaoFeng Wang, Kai Chen, Yuan Tian, Carl A. Gunter, Kehuan Zhang, Patrick
Tague, and Yue-Hsun Lin. Understanding iot security through the data crystal ball: Where we
are now and where we are going to be. "https://arxiv. org/abs/1703.09809", 2017.
[6] Abdillahi Hassan Adnan, Mohamed Abdirazak, A.B.M Shamsuzzaman Sadi, Towfique
Anam, Sazid Zaman Khan, and Mohammed Mahmudur Rahman. A comparative study of
wlan security protocols: Wpa, wpa2. http://ieeexplore.ieee.org/ document/7506822/, 2015.
[7] Indiana University. What is the principle of least privilege? https://kb.iu.edu/d/ amsv,
2017.
[8] A. Perrig et al. In The Tesla Broadcast Authentication Protocol , CryptoByte, vol 5, pages
2–13.
[9] George Hatzivasilis, Ioannis Papaefstathiou, Konstantinos Fysarakis, and Ioannis
Askoxylakis. Secroute: 2end-to-end secure communications for wireless ad-hoc networks. In
Computers and Communications (ISCC), 2017 IEEE Symposium on, pages 558–563. IEEE,
2017.
[10] Earlence Fernandes, Justin Paupore, Amir Rahmati, Daniel Simionato, Mauro Conti, and
Atul Prakash. Flowfence: Practical data protection for emerging iot application frameworks.
In 25th USENIX Security Symposium (USENIX Security 16), pages 531– 548, Austin, TX,
2016. USENIX Association.
[11] Yan Michalevsky, Suman Nath, and Jie Liu. Mashable: Mobile applications of secret
handshakes over bluetooth le. In Proceedings of the 22nd Annual International Conference on
Mobile Computing and Networking, pages 387–400. ACM, 2016.
[12] Aurelien Francillon, Boris Danev, and Srdjan Capkun. Relay attacks on passive keyless
entry and start systems in modern cars. https://eprint.iacr.org/2010/332.pdf.
[13] Torry Harris. Cloud computing services—a comparison. International Journal of
Computer and Information Systems, 3:1–18, 2010. 54
[14] Google inc. Eddystone format. https://developers.google.com/beacons/ eddystone.
[15] Google inc. Eddystone ephemeral identifier. https://developers.google.com/
beacons/eddystone-eid.
[16] Sitepoint tutorials. What is a rest api. https://www.sitepoint.com/ developers-rest-api/.
[17] Tutorialspoint. Android architectural layers. https://www.tutorialspoint.com/
android/android_architecture.htm.
[18] Android developers. Andriod manifest. https://developer.android.com/guide/
topics/manifest/manifest-intro.html.
[19] Particle IO. Security check list of internet of things. Security check for iot devices, 3:7–
9, 2017.