Due to growing popularity of smart home systems, smart home security is a topic which is becoming increasingly important. Internet of Things (IoT) devices are obtaining increasing access to private data, but very often it does not mean that improved security mechanisms and mechanisms guaranteeing availability are implemented. The main problem is limited computing power and the limited memory of the nodes used in the network. Moreover, IoT systems are increasingly often managed through the cloud, which causes that their interfaces are available over the Internet. Another problem is the lack of expertise of users which can lead to configuration errors potentially causing data loss and hacker attacks. In this paper, we face up security and availability issues in smart homes and propose an edge-of-things solution that focuses on putting the management of the home at the edge. The management is controlled by the network operator in a similar way as occurs with current set-top-boxes for multimedia streaming at home. We propose an architecture for this system, implement the necessary modules and test it from the point of view of security and availability. The results show that the proposed edge-of-things solution is able to solve many of the challenges that current smart home applications present.
1 Introduction
Smart homes are becoming more and more popular with the introduction of a high number of Internet of Things (IoT) [1, 2] applications (heating, ventilation, air condition—HVAC, multimedia and alarm systems, lighting, home appliances, etc.) and respective smart devices, many of them being connected directly to the Internet for making remote management feasible. Connectivity to the Internet together with limited processor capacity of smart home devices and increased popularity of such systems introduces serious challenges to security/privacy and to efficient management of the smart home. The most important challenges are the following: First, the nodes used in home area networks (HAN) usually have limited hardware resources—computing power and memory. This makes it very difficult or impossible to implement complex algorithms that ensure security [3]. Secondly, an increasing number of smart home systems use the cloud to provide some of their functionalities [4]; this means that the interfaces are available on the Internet, which potentially allows access to them by unauthorized persons [3]. Thirdly, wireless communication protocols used in IoT devices are not fully protected against attacks [5]. In the case where devices using them are connected to the Internet, they can be used by hackers as points of “entry” and further attacks. There are known cases where IoT devices, such as, CCTV cameras, have been used for DDoS attacks. Next, the multitude of wireless standards—it leads to a lack of compatibility between the devices offered on the market and complex implementation of comprehensive consumer applications. Currently, the most popular wireless communication standards applicable to smart home applications include: WiFi [6] (e.g., Phillips Hue bulbs), ZigBee (e.g., remote-controlled Samsung SmartThings Outlet) [7], Bluetooth (e.g., digital Goji lock) or Z-Wave (e.g., Leviton switch). Although these standards often work on the same frequencies, the devices in which they are implemented are not compatible with each other [8, 9].
Other challenges of smart homes are: (1) troublesome configuration—currently, apart from the solutions offered by individual manufacturers, the configuration of smart home devices may be too complicated for the average user [10‐12]. The problem of security and privacy is particularly visible here. The user is not able to easily control which data and to what extent devices connected to the HAN network have access to his home [13]; (2) lack of a uniform programming interface—it results in the inability to create generic applications that allow reading data and executing commands on devices of the same type (with the same functionalities) offered by different manufacturers (e.g., smart light bulbs); (3) continuous availability of devices—from the point of view of many smart home applications (a large part of which focuses on improving the safety of household members), it is crucial for ensuring reliable and correct work.
Anzeige
All the problems mentioned above make the implementation of smart home systems complicated, expensive and in many cases unprofitable. In addition, there are many doubts related to the safety of using IoT devices in comparison with the use of conventional devices (e.g., the use of locks for doors controlled via Bluetooth, compared to standard ones) [14]. One solution is the introduction of the edge-of-things approach [15‐17], which consists of separating at the network level the devices inside the home and putting intelligence at the edge in order to take control of key functionalities of the system. The result is a home automation system (HAS), which keeps at the edge the security, privacy and some management functionalities. The responsibility of such edge-of-things maintenance is trespassed from the end users (which are generally unaware of the technical complexity of security/privacy/management issues) to the network operators.
This paper shows a solution for HAS management, where the management processes are shared between the home gateway and the management system situated at the network operator’s premises. The proposed solution applies some solutions presented by other authors such as [18‐20]; however, our system implements all the basic functionalities and presents the concept of unified API, which makes the full operator-based management feasible thanks to the new business model. (The operator offers smart home service and is the responsible for interoperability communication.) Based on our proof of concept, the full system may be developed and prepared to be commercialized. Unified API and the approach presented here is an example of edge computing for the Internet of Things [21]. This “edge” is composed by a network operator-owned gateway located at the home and the management system situated at the network operator’s premises. The gateway will allow to remote control and manage the smart home devices. The gateway will be designed with the assumption that the entire configuration will be remotely controlled by the operator, on similar terms as in the set-top-box devices currently offered and used to reception of television [22‐24]. Adding new devices to the home area network (HAN), managing them, as well as downloading data from sensors and controlling executive devices will be carried out using the universal programming interface (unified API) [25, 26]. The gateway will allow to translate the functions of this interface into functions offered by programming interfaces provided by manufacturers of individual devices connected to the HAN (vendor API). Thanks to this, different wireless network standards used by devices connected to the HAN network will be transparent for programmers using a universal programming interface.
The gateway will be connected to the management system in network operator’s cloud, which in turn will allow to remote control the gateway operation and updating the software located on it (on the gateway). As a result, an appropriate level of control and management mechanisms that cannot be implemented on the capacity-limited end nodes will be provided by a cloud-based system without such limitations [27, 28].
The operator managing the gateway and the management system will be responsible for ensuring security at many levels, in terms of data transmission outside the HAN network and data transmission within the network. Therefore, a great emphasis in this solution will be placed on the use of methods of managing the system that enable secure exchange of information between its various elements.
Anzeige
The last element of the system will be a user’s mobile device that will allow reading data from sensors and controlling executive devices, as well as managing privacy and permissions of individual devices connected to HAN.
The main design assumptions of the presented edge-of-things system for HAS include:
The ability to remotely configure and manage smart home devices by the operator using a unified programming interface.
Possibility to configure, control and collect data from end nodes implementing various wireless communication protocols (e.g., WiFi, Bluetooth, ZigBee [29]) using a unified application programming interface (called unified API).
Ensuring system security and continuous availability of smart home devices [30]. Communication between individual system elements should take place using protocols that ensure security and privacy, and user authentication should be carried out in a way that prevents access to the system by unauthorized persons.
The delimitation of responsibility for individual components of the system is very important, and it is worth emphasizing here. Managing applications would be operated entirely by an operator offering a smart home service. The gateway would be installed in the home of the end user, while the operator would be responsible for the configuration process and its maintenance.
In the next section, we discuss current approaches to the HAN management jointly to their limitations. In Sect. 3, we specify the edge-of-things system for home automation systems and provide details of our implementation. Section 4 presents test results of our implementation. These tests are directly related to security and privacy. At last, we conclude the paper in Sect. 5 by providing the main characteristics of our system.
2 Security in smart homes
Security and privacy are the biggest concerns when developing solutions for smart home [31]. Breaking the security of a smart home system can lead to unauthorized access to private data (e.g., recordings from video cameras) [32‐35] as well as to bypass physical security (e.g., locks, gates, blinds) of a given object (e.g., [36]). In the worst case, unauthorized persons may gain access to systems strictly responsible for household security (e.g., carbon monoxide or flooding detectors) and cause irreversible material damage [37]. For this reason, it is very important to identify all kinds of weaknesses and to address problems that can lead to unauthorized access to management of smart home systems and their data [38].
In connection with the above, the requirements for smart home applications include [39]: user’s privacy, reliable authentication and authorization, non-repudiation, continuous availability of devices as well as integrity.
2.1 Challenges
OWASP (Open Web Application Security Project) has published a list of 10 security/privacy threats, in which IoT systems are particularly susceptible to attacks: unsecured web interface, insufficient authentication/authorization, unsecured network services, no encryption, doubts about privacy, unprotected cloud interface, unprotected mobile interface, insufficient configurability, insecure software/firmware and poor hardware security.
Within each of these categories, difficulties in addressing them were defined, and recommendations for IoT devices/software developers were proposed, which form a set of basic requirements related to the security of IoT systems [40]. In addition, a set of test tasks has been published that allow the user to check the compatibility of the created system with the security standards.
There are many methods that can be used by hackers to gain unauthorized access to private data managed by smart home systems [39, 41]. Some of these methods are passive methods that rely on reading data without modifying it. Such attacks are particularly dangerous, because they can be carried out in such a way that the user will not even know that the security of his system has been broken and unauthorized persons have access to the data stored in it. Specific scenarios of passive attacks include eavesdropping and traffic monitoring [42‐45].
Eavesdropping consists in intercepting data sent over the network. HAN networks are particularly vulnerable to such attacks due to the fact that they use mainly wireless communication, and in addition, protocols used for transmission are often very poorly secured [46]. This is due to the fact that in HAN networks, the nodes often have limited computing power, which means that it is not possible to implement full versions of network protocols. Confidential data captured from smart home systems usually allow to take detailed information about user activity. An example of this can be a system of smart locks, controlled by smartphones, using the Bluetooth LE standard, which transmit the user’s password in an unencrypted form. This type of system can easily be taken over by unauthorized persons (after the password has been taken over using a sniffer). Professional devices (sniffers) designed for testing of created systems can be used to carry out such attacks.
By using Traffic monitoring the attacker does not get access to the data itself, but on the basis of their flow is able to draw conclusions about the system user’s activity [47]. An example is the analysis of network traffic leading to the detection of repeated patterns of the absence of household members. This kind of information can be used for physical attack on the house.
Passive attacks can be carried out both in the physical layer (e.g., sniffing—interception of network traffic, jamming—interference with the wave by radio waves interfering with waves sent by nodes or spoofing—impersonation of another device), as well as in higher layers.
Such vulnerability may be caused by errors in the implementation of protocols used for transmission as well as lack of encryption and verification of the integrity of transmitted data. The attacks mentioned above pose a threat to the privacy, integrity and authenticity of the system affected.
Another type of attack is active methods. They consist in introducing false information to the system by the attacker—by changing the data transferred in the system, or adding new ones. Examples of such attacks are the following:
2.1.1 DoS (denial of service) attacks
Such attacks consist of blocking authorized users access to the system [48]. It is usually carried out by introducing a large number of false messages to the network, which in turn may lead to network overflow and blocking. These attacks can be carried out in every layer of the HAN network and make use of the fact that nodes in HAN networks usually have very limited computing power. The attacker sends a large number of messages to a susceptible device and consequently blocks the transmission. Also the introduction of a large number of messages to the network (even those that do not require the involvement of other resources and their responses) is able to block the attacked network.
2.1.2 Identity theft and masquerade attack
In this case, the attacker uses a fake identity to gain unauthorized access to the resources.
These attacks are carried out using stolen data credentials/authorizing the user in the system, or they use security holes in the authentication processes. Very often this type of attack is used as a prelude to perform subsequent unauthorized activities in the system and to take control of the attacked device.
2.1.3 Replay attack
In this case the attacker intercepts the message sent by the authentic user of the system (e.g., by means of a sniffer) and then sends it to the recipient, impersonating someone else’s identity. On this basis, it can access to resources available to the original sender of the message. As the examples described in the literature show, there are many smart locks susceptible to such attacks. This leads to a real threat of hacking into the object using the attack on the smart home system.
2.1.4 Packet interception
In the case of this kind of attacks, information sent on the network is received by the attacker, so they cannot reach their real recipient. This may, for example, prevent the control of individual execution nodes connected to the network or the reading from the sensors that are in it [49].
2.1.5 User session theft
The attack consists in using the session control mechanism, which in most cases is carried out using a token. The attacker intercepts the token and then uses it to get to the resources hidden behind it. The token can be captured in a variety of ways: using a sniffer or using scripts installed on communicating devices.
2.1.6 Message modification attack
In this case, the attacker changes the message (e.g., its headers) in such a way that it is passed to another destination address or changes its content.
2.1.7 Unsecured interfaces
The use of errors in the implementation of interfaces used by HAN systems is also described in the literature. An example of this is the weak authentication and authorization mechanisms used in the API management applications working in the cloud. Such applications usually store very large amounts of data collected from the user’s sensors. In the event that it is possible to break the authentication mechanisms, the attacker can access the data by performing appropriate queries to the system.
2.1.8 Malicious software
Uploading malicious software onto any system components can be used to capture data as well as unauthorized system manipulation. This type of code can be placed on the device using various methods. Literature includes, among others, unprotected physical interfaces (e.g., USB ports, or SD card readers), badly designed update processes (and the ability to upload any other files to the device), as well as security deficiencies in wireless network protocols. Thus, the ability to upload malware to a device can be caused by both errors in the implementation of hardware and software.
2.2 Counteraction
Implementation of security solutions is particularly difficult in smart home applications due to the considerably limited computing power of nodes, as well as the fact that most HAN networks are heterogonous [50]. That is why in many implementations of HAN networks there are a very large number of errors that allow to carry out the attacks mentioned in previous chapter. Therefore, it is necessary to undertake actions aimed at introducing mechanisms that ensure a sufficient level of security in the HAN network. Among them: use of security mechanisms offered by wireless protocols used for communication (transmission encryption), reliable access control-providing reliable authentication mechanisms that allow reading data/managing devices connected to the gateway only to authorized persons, blocking the possibility of interference the software controlling the gateway, prevent the connection of additional unmanaged devices to the network gateway, storing and analyzing sensor data only locally—on a network gateway and sending data to the cloud only in encrypted form, using at least 256-bit keys and, at last but not least, service repairs of devices only by trusted third parties (e.g., operator).
Specific security operations in HAN are.
2.2.1 Authentication and authorization
The HTTP and MQTT [51, 52] protocols used for transmission in the system allow to use the TLS protocol [53], which has built-in authentication mechanisms. In addition, OpenID and OAuth mechanisms can be used that significantly accelerate the creation of a credible authentication and authorization path.
Moreover, it is very important to provide mechanisms that will reduce the effectiveness or completely block the possibility of brute-force attacks and dictionary attacks. To this end, the following mechanisms should be used: blocking the account after entering the password a few times, applying a policy that prevents the user from setting a too-weak password and using secure password recovery mechanisms.
Another mechanism that improves security is the use of two-factor authentication. It is assumed that these factors are the knowledge and the ownership components. The knowledge component is that the user is able to prove the knowledge of a secret message (e.g., password). The ownership component is instead that the user must confirm the possession of a certain thing. It can be, for example, a smartphone, to which a text message will be sent, which should be provided in order to complete the authentication process.
In the case of authorization, it is very important that the user has access only to those resources that are intended for him. Therefore, it is important to provide control mechanisms allowing for analysis, control and possible changes in the rights granted to individual users.
2.2.2 Allocation of rights
The user should be able to easily control the permissions granted to individual devices connected to the HAN network. The set of data collected by a specific device should be clearly described, and the user should be able to change individual settings. It is important that the user can limit the scope of data collected by a given node only to those that are necessary for its proper operation. Access to any type of additional data should be granted optionally and communicated to the user in a clear manner.
2.2.3 Privacy
Providing the desired level of privacy can be achieved by: encryption of all transmitted information, correct implementation and maintenance of TLS to encrypt data in the transport layer and not using personal data encryption solutions—the use of a commonly used, tested algorithm is the preferred solution for secure IT systems [54].
Correct application of TLS to all types of transmissions occurring in the network significantly reduces the possibility of passive attacks aimed at eavesdropping on transmitted data.
2.2.4 Continuous availability
Another important issue related to smart home applications is the assurance of continuous availability of devices from both a hardware and software point of view. In the case of hardware solutions, these can be: adequate protection against physical attacks and introducing spare battery power for allowing further work in the event. In the case of software solutions, these are: introduction of a remote update mechanism that allows the user to remove program errors and implement fixes, ensure that the user updates in a timely manner from the detection of a threat and create encrypted data backups that will allow the user to restore the initial state in the event of a device failure.
3 Specification and implementation of the system
The system will consist of three main components, as presented in Fig. 1: (1) smart home gateway installed in users’ households, (2) management system working in network operator’s cloud and (3) mobile device acting as an interface to manage and control HAN network.
Fig. 1
High-level architecture of the proposed system
×
3.1 Smart home gateway
In this section, we present implementation details of the developed home gateway. The smart home gateway is a device provided by network operators similarly to set-top-box devices. Since gateways will be managed by network operators, it will be possible to assure appropriate security level by providing regular software updates and safe communication means for both internal and external communication.
Smart home gateway will be responsible for manipulating IoT devices connected to a HAN network (e.g., smart lighting, thermostats, locks, shades). It will be connected to the Internet, thus enabling control of devices from outside of a house and also remote control by a network operator. Gateway will be also responsible for translating unified API functions to vendor APIs of various devices connected to a HAN network. Thanks to this, it will be possible to control all connected devices using unified functions, which will not be dependent on the standards implemented by these devices.
It is also important the fact that by updating firmware running on the gateway, the network operator will be able to add new types of devices (new vendor APIs) completely remotely. This will allow to react appropriately to new devices being released to the market by adding possibility to connect them to the gateway. Gateway’s firmware will also allow to add an abstraction layer to devices connected to itself—nodes will be recognized and categorized by their functionalities and not wireless communication standards.
During implementation of the gateway’s software strong emphasis will be put on the security of the transmission inside the HAN network (all traffic will be coming through the gateway, so that it will have a 100% control over the network), but also on the transmission between the gateway and management system working in network operator’s cloud. Because the gateway will be a point of contact between Internet and smart home devices, it needs to provide a security level, which prevents from unauthorized access to the HAN network from the outside. Moreover, to provide the continuity of the devices operations, it will have to provide correct operations also in the situation in which there is no Internet access.
In our prototype, the smart home gateway will be based on a Raspberry Pi computer running a Raspbian operating system (Linux distribution adjusted for this particular hardware). This solution was chosen since it offers sufficient performance, all interfaces required in our conception and also flexibility when it comes to implementing software and choosing technologies which best suit the implementation needs. This approach will also allow to upgrade the features of the system in the future.
In our prototype, Python was chosen as a language of implementation. This choice can be backed up by the following factors: (1) good availability of open-source libraries, which significantly speed up the implementation and simplify the integration with external components, (2) syntax which allows for fast software implementation (similar software written in Python is in average 3–5 times shorter compared to Java) [55] and (3) sufficient performance for our necessities.
To provide implementation of the communication using the MQTT protocol an open-source library [56]—paho-mqtt library—was used. HTTPS communication is provided by using http.client module. Local data storage is implemented using document-oriented MongoDB database. To speed up implementation an open-source module (PyMongo) was used. It provides methods to store and retrieve data from the MongoDB database. The gateway implements the following features:
Authentication of the gateway in the management system.
Adding new HAN devices/nodes. This functionality was simulated in the gateway’s firmware. When a user adds new node to the system by using a graphical user interface, a request is sent to the management system. Management system updates its database, which contains gateway configuration information. Then, it sends a message to the gateway using MQTT protocol by which it informs about the newly added device and thus the need of configuration update [57]. After the message is received by the gateway, it sends configuration update request via HTTPS protocol. After the response is received, the local gateway database is updated, and the newly added device can start communication inside the HAN network.
Control of actuators/reading data from sensors, which has been implemented with MQTT protocol secured by TLS protocol [58]. MQTT broker is working in the cloud and is available for both the gateway and the mobile devices used as a mean to control the system. The gateway calls connect function to establish a connection with the broker and then subscribes to topics by using subscribe function. Because of this, devices in the HAN network can be controlled based on the received messages. In case of sending data from sensors to the management system database MQTT publish function is used. Information is published to appropriate topics. Topic’s format is set to be as follows: {gateway_identifier}/{device_identifier}.
3.2 Management system
In the following section, the functionalities of the management system for smart homes situated at the network operator’s premises are presented. We provide, in addition, implementation details of the proof of concept of the management system that we developed. Main role of the management system is to control and manage the operation of the gateway. It will be responsible for configuration and updates of gateway’s firmware. Because of this, network operator will be able to remotely add support for new communication interfaces between the gateway and smart home devices (vendor API). The management system will also provide the gateway with all the necessary security updates.
The management system will be also a broker for the communication between the gateway and user’s smartphone, which will allow for the remote access to the devices working inside the HAN network (only when the user will be controlling the system from outside of the HAN network). A user will also have the possibility to read sensor data and to control actuators by connecting to gateway using his own mobile device (partially through API via the management system or directly thanks to the access to the API through the local network)—sensor data and also user’s activities will not be stored on a server, so that 100% privacy and anonymity will be provided.
Management system will also provide a way to handle user’s authentication and will also store information about the access levels assigned to particular devices by the user of the system. This will allow to detect unauthorized access to the HAN network. It is also very important to provide safe communication between the management system and the gateway because this channel will be used to send sensitive user data, important from the point of view of the security of the whole network.
The management system will be implemented in the cloud using Python programming language. The choice of this language was influenced by the same factors as in case of the already described implementation of the gateway. To speed up the implementation Flask framework was used in which features like REST support. The system will run in Microsoft Azure cloud’s App Service component. This will allow for remote access to the system and enable to better test the implemented project in comparison with running the code on a local server. It is worth noticing that features such as authentication/authorization, code deployment directly from Git repository and backend status monitoring are built into the Azure App Service, so the time needed to implement it in a cloud should be radically reduced. Since the system will be working in the cloud, it is very important to provide security and integrity of all the data. That is why it is necessary to implement mechanisms protecting these data from any potential attacks.
The management system implements the following functionalities:
Passing messages to a gateway when a user is outside of a local network. When a system user is outside of a local network in which a gateway is installed, all MQTT messages are sent to it using a MQTT broker working in a cloud. Therefore, a user can remotely control his devices, even if he is outside of his house. His mobile device publishes MQTT messages under appropriate topics, and then, they are sent to a gateway using a broker working in a cloud.
Storage of data gathered by sensors. All data which are gathered from the sensors attached to the HAN network are sent to the management system and stored inside a database. A user has access to historical data using a mobile application installed on his mobile device. All requests for such data are sent using HTTPS protocol.
Gateway configuration updates and translation from unified API to vendor API. When a user adds new device to the HAN network using mobile application installed on his mobile device, a request to the API is sent alongside with device’s parameters. This allows for its identification and also to translate unified API functions to vendor API functions.
Management system was implemented on the Azure App Service platform in Python language and Flask microframework. All data are persisted in a NoSQL database program—MongoDB. The system consists of three main components:
REST API (HTTPS)—it was implemented with the help of flask_restful module, which can be used to implement APIs with Flask framework. The API exposes methods which allow to add new gateways to the system and manage them. It enables the adding and removing of devices in particular HAN networks and uploading software updates to gateways.
API GET methods (non-exclusively):
/api/gateway/< string:gateway_id >—downloads information about a gateway with identification number expressed by a gateway_id parameter
/api/device/< string:device_id > —downloads information about a device with identification number expressed by a gateway_id parameter
/api/config/< string:gateway_id > —downloads most up-to-date configuration for a gateway with identification number expressed by a gateway_id parameter.
API PUT methods (non-exclusively):
/api/device—adds to the system information about a device described in a message body
/api/gateway—adds to the system information about a gateway described in a message body.
All abovementioned methods must be sent alongside with an authentication token, which confirms identity in the system. Otherwise, no integration with the system is enabled.
Following services have been used in the implementation:
Auth0 service (working in a Software as a Service model) was used to enable functionalities related to authentication. It provides API which allows for easy integration of authentication and authorization mechanisms with a system. This API is available for multiple programming languages such as Python and iOS/Swift which are used in this project. This solution is easily scalable, supports standards such as JSON Web Token, OAuth 2.0 or OpenID and allows for integration external identity provides like Google or Facebook.
CloudMQTT is a service which provides a broker for MQTT protocol which can be installed in a cloud and thus easily accessible from the Internet. It provides built-in encryption with TLS. In the implemented system, the broker is responsible for coordination of whole communication between mobile device and the gateway. Moreover, MQTT protocol is used to send information about the availability of new software updates from the management system to gateways.
3.3 Mobile device
The last involved device is the mobile device, which remotely may have access to the smart home. In this section, we present the functionalities of the mobile device for having secure access to the home devices. For this, the mobile device (e.g., phone) must agree with the network operator’s management system the conditions of the access. In this section we present the characteristics of such a communication and present the developed modules to be installed in the mobile device.
The smartphone/tablet of the end user will be a controller, thanks to which the user can communicate with the gateway and read the data from the sensors and control the actuators. Moreover, the smartphone/tablet will be used in the course of authenticating the user in the system. By logging in the user will obtain access to managing and controlling the gateway (both remotely and locally). The authentication and authorization of the user will take place through a cloud management system.
The mobile device will also serve as an interface, allowing the user to control the gateway and hence manage the entire HAN network. This element of the system will be implemented in Swift language as a native iOS application. The iOS operating system is currently the second most popular operating system for mobile devices in the world; therefore, the final solution should also encompass services for devices using this operating system.
The application will make use of the libraries such as Moscapsule—a library implementing the MQTT protocol. Moreover, custom solutions allowing for a safe exchange of keys between the mobile device, the gateway and authentication of the device in the management system will be developed.
The mobile application was implemented for the iOS operating system. The application was developed using the Swift language. For the development and building of the application integrated development environment delivered by Apple was used—i.e., Xcode in the 8.3.1. version and the iOS SDK (Software Development Kit). The application uses external open-source libraries: Alamofire—asynchronous communication using the http protocol, Moscapsule—communication using the MQTT protocol and Lock—SDK allowing for integration of the Auth0 service with the mobile application.
The CocoaPods software, which allows for easier integration of the project with external libraries, was used to manage dependencies. Below, the main scenarios for the use of the mobile application shall be presented, together with a detailed description of the mechanisms used for their implementation:
3.3.1 Authentication/authorization of the user in the system
The first functionality, particularly important from the perspective of the entire system, is authentication and authorization of the user in the system. After registering, the user is asked to provide its login and password. What should be underlined, is in order for the user to log into the system; the password must fulfill the following prerequisites: comprise of at least 10 characters; the characters being of at least 3 out of 4 types (small/big letters, numbers, special characters); no more than two identical characters next to each other. Such strong passwords allow to prevent the system from brute-force and dictionary attacks.
In reply, the server allows the user to log in the system. If the logging in is successful, the authorization procedure is launched and access to particular resources is granted on the basis of previously defined rules. The granting of access takes place in the managing application on the basis of the user’s identification sent from the Auth0 service.
After providing the login and password by the user, the data are sent using a HTTPS protocol to the Auth0 service. Once the authentication of a user in the system is successful, the Auth0 service returns the refresh token, which allows the user to use the system in more sessions, without the need for providing the data for logging in on each occasion. The token is saved in a secure keychain on the mobile device, and later is used for authentication of every request to the managing system. After a successful login, the screen enabling management of the entire instance of the smart home is also opened. The functionalities of this screen are described in the following chapters.
3.3.2 Adding a new device to the HAN network
From the mobile application, the user can also add new devices to the HAN network. What is noteworthy, is that only devices that had been authorized by the operator of the system, can be added. Simultaneously to adding the device, a request for granting particular permissions appears. Those permissions are grouped into categories, and the user is capable of controlling each of them separately. The device can use the functionalities only within the permissions that it was granted. The user may also change the permissions granted to particular devices at a later stage of using the application.
Adding the device is noted in the cloud application of the operator. Hence, the operator can control and, in consequence, be accountable for the whole network traffic received and generated by a particular node.
3.3.3 Reading data from sensors/controlling actuators
After adding devices to the HAN network, the user can control the device and read data originating from it (depending on whether the device is a sensor or an actuator). If the user is in the same local network as the gateway, requests for reading of data or commands to the devices in the HAN network are sent using the MQTT protocol, using the MQTT broker installed on the gateway and accessible locally.
Where the user is not in the local network, in which the gateway is installed, the communication takes place using the CloudMQTT broker, installed in the cloud. This solution allows for using the system in two situations: lack of Internet access from the gateway, i.e., the system is controlled locally and remote control from outside of the network of the gateway and the smart home.
3.4 Mechanisms for secure edge of things at the home
As has already been presented in the previous chapters, adequate management and safety of communication between particular components of the designed system is of key importance. The system implemented in this work was designed with the aim to address the issues described in chapter 2. Hence, mechanisms significantly reducing the possibility of attacks and protecting the user from most popular perils were also implemented [31]. In this chapter, the protocols and methods used in exchange of information in the system shall be described.
It ought to be noted that the transmission taking place outside of the designed system should be encrypted in a manner rendering it impossible for the information that is sent to be read. Therefore, the use of the public key cryptography is crucial since it allows for safe transmissions between particular components of the system.
3.4.1 Authentication and authorization
The authentication and authorization in the designed system can be divided into 3 parts, all of them being managed by the network operator (i.e., the operator accepts or rejects each of these authentications):
The authentication and authorization of the end user. The user will be logged into the system through a mobile device with a native mobile application installed on it. The mobile device will communicate with the operator’s cloud, where the authentication and authorization of the user shall take place, and where following this access to particular resources of the system will be granted.
In the previous chapters attacks were described, which took place due to wrongly implemented authentication and authorization in particular systems. Additional mechanisms addressing the reasons for those attacks must therefore be implemented. In order for the authentication of the user to be as safe as possible, the two-factor authentication mechanism shall be used.
The authentication and authorization of the gateway. The system designed in the course of this work will also include a gateway that will be authenticated in order for the identity to be confirmed and authorized in order to grant access to particular resources. Public key mechanisms shall be used for this purpose. The first part of the authentication of the gateway will take place automatically, after connecting to the network. The gateway will be identified by a combination of the serial number and a certificate installed by the manufacturer at the stage of pre-configuration. The second phase of the authentication of the gateway will be the user typing in its login and password in an interface displayed on its smartphone. The login details will be sent to the gateway in encrypted form and later sent on by the gateway for the authentication in the management system. After completing the authentication procedure, a token allowing for later interactions with the system shall be sent to the gateway.
The authentication and authorization of devices connected to the network. Authentication and authorization should also apply to all devices connected to the HAN network. Unauthorized devices will be blocked by the gateway and will not be able to transmit in the HAN network nor accessible over the internet. Consequently, the possibility for unauthorized transmission within the system will be blocked.
3.4.2 Safe communication
Communication between the components of the system will take place thanks to safe protocols assuring required efficiency and functionalities appropriate for particular elements of the system. In the designed system the following sections on which the communication takes place can be distinguished:
Communication between the gateway and the management system, which is used to: (1) authenticate and authorize the gateway, (2) authenticate and authorize the devices connected to the HAN network (sensors and actuators), (3) remote reading of data from sensors connected to the HAN network, (4) remote control of the actuators through a mobile device and (5) sending updates from the management system to the gateway (safety updates and updates for new vendor API) and configuration messages.
The HTTPS protocol is used for sending data used for authentication and authorization of the gateway as well as the devices connected to the HAN network. The protocol is also used for the sending of configuration messages and updates to the gateway. HTTPS is an encrypted version of the HTTP protocol, which for this purpose uses the TLS protocol. Thanks to this, the transmission is protected from man-in-the-middle attacks, wire tapping and its credibility is confirmed.
For the transmission of data originating from devices connected to the HAN network, the MQTT protocol shall be used. It has been selected due to its lightweight and simplicity. It is an ideal choice for applications, where the lowest computational complexity and use of energy are of upmost importance. It can be used on resources with very low throughput—the data are sent in the form of a bite array, and the size of the header is only 2 bites. Moreover, it possesses 3 QoS levels, which significantly improve implementation. In terms of transport layer, the MQTT protocol can use the TLS protocol.
Communication between the gateway and devices connected to the HAN network. Bluetooth LE, WiFi and ZigBee protocols are used for the communication between the gateway and HAN network devices.
Communication between the mobile application, the gateway and the management system. The mobile application communicates with the gateway through MQTT or HTTPS protocols. The MQTT protocol is used for sending commands to the actuators in the HAN network and receiving data from sensors. The HTTPS protocol is used for the authentication and authorization of users in the system.
4 Tests
The tests provided in our implementation aim to show whether the Pilot has been developed as it was specified. Generally speaking, the conformance tests goal is to determine whether a particular piece of equipment satisfies the specified criteria of operation. Conformance testing methodology defines the boundaries of the system under test (SUT), i.e., both the HGW and the operator’s management system, as well as the test system (tester) responsible for monitoring the SUT behavior. Because the tester controls the sequence and content of the protocol messages sent to the SUT, it can impose a wide range of both expected and unexpected (invalid) behaviors.
On the other hand, the purpose of interoperability tests, according to ETSI TR 101 667 [59], is to prove the functionality between, at least, two communication elements situated in operating environment. In opposite to conformance testing, interoperability tests are performed on interfaces that provide normal user control and observation. Interoperability tests are based on functionality accessed by the user.
The tests are based on conformance methodology, so the tester (our PC) sends messages in order to check the response of the SUT. The messages are sent one-by-one and the response of the SUT is then analyzed, and conclusions are taken. Both the systems (HGW and management system) are tested separately and in isolation (as required in conformance testing). We divided the tests between conformance (about the general operation of the systems) and security (specific for security functionalities).
4.1 Conformance tests
Conformance tests were performed to examine whether the system designed in the course of this work correctly implements functionalities described in the system specification. For this purpose, the following functional tests were performed.
4.1.1 Adding a gateway to the system
During this test a new gateway was configured in the system. The following steps were undertaken:
1.
Sending API, a request to create a gateway
2.
Adding a new user who has access to the gateway to the system
3.
The user connects to the gateway locally followed by the user’s authentication
4.
The gateway was properly authenticated—i.e., the result of the test resulted positive.
4.1.2 Adding devices to the HAN network using a mobile device
The test was to add a new HAN network device to the previously configured gateway using a mobile device.
1.
The user is authenticated in the mobile application
2.
The user selects the option “Manage devices”
3.
The user selects the option “Add device”
4.
The user fills in the details of the device and confirms adding the device to the system
5.
Verification in the databases of the management system and the gateway that the new device has been added
6.
The device is added to both databases—i.e., the result of the test resulted positive.
4.1.3 Data reading/sending control commands
The test was to send control commands and read data from the gateway using a mobile device.
1.
Preliminary prerequisites—the user is logged in the system and has at least one device added to the gateway
2.
The user chooses the option on the mobile device “Control devices”
3.
The user chooses from a list the device that it wants to control
4.
On a separate terminal, a connection to the gateway using SSH and the reading of the logs displayed in the console by the gateway, takes place
5.
In the console the logs sent to the gateway by the mobile device are visible
6.
On the mobile device, the information sent by the gateway is displayed—i.e., the result of the test resulted positive.
4.1.4 Verification of the implemented solution with the design assumptions
The system designed in the course of this work has also been tested against the design assumptions made at the outset. Table 1 presents such assumptions jointly to the result of the tests and reasoning of results.
Table 1
Compatibility test results
Design assumptions
Result
Reasons
The possibility of remote configuration and management of the smart home devices by the operator, using a unified software interface
Positive
Cloud API was implemented, which enables the control of new gateways as well as new devices in the HAN network. Therefore, it could be used by an operator of smart home services for the purpose of configuration and management of a HAN network
The possibility of configuration, control and collection of data from end nodes, using unified API
Positive
API which uses HTTP and MQTT protocols was implemented, allowing for the control of HAN network nodes that were added to the system through unified API. Interfaces allowing for later translation from unified API to vendor API have also been developed
Maintaining security of the system and constant accessibility to smart home devices
Positive
Mechanisms such as encryption or two-factor authentication have been used. Detailed tests and analysis of the project in terms of security will be presented in next section
In the table the results of compatibility tests of the system against the design assumptions have been presented. All design assumptions have been fulfilled in the implemented system. What should be underlined, is that the system implemented in the course of this work is a prototype and has a number of limitations. Nevertheless, the implemented solutions can serve as a starting point in the design of a safe gateway for a smart home.
4.2 Security tests
Security tests were based on the test set proposed by OWASP project. It allows to check if the implemented project is compliant with basic security requirements. From the proposed test set only test cases which are relevant to our implementation were chosen. Table 2 presents the test description and results.
Table 2
Security test results (subset of test cases proposed by OWASP IoT project)
Category
Test case
Result
Insecure web interface
Assess any web interface to determine whether weak passwords are allowed (less than 10 characters, less than 3 types of characters, more than 2 repeated characters). Process:
Try to type in a weak password on sign-up screen
User’s request is denied by the application
There is no possibility to use a weak password in the system
Positive
Assess the account lockout mechanism. Process:
Try to log in with a wrong password for 10 times
User account gets blocked
There is no possibility to log in without prior confirmation of identity via email
Positive
Assess the use of HTTP to protect transmitted information. Process:
All interfaces using HTTP protocol have been analyzed
It was confirmed that TLS protocol is always used for HTTP communication
Positive
Insufficient authentication/authorization
Assess the solution for the use of strong passwords (more than 10 characters, more than 3 types of characters, no repeated characters) where authentication is needed. Process:
Authentication service settings were assessed
It was confirmed that strong passwords are always required from the user
Positive
Assess the solution for multi-user environments and ensure it includes functionality for role separation. Process:
Role settings in authentication service were assessed
It was confirmed that it is possible to assign different roles to particular users
Positive
Assess the solution for implementation two-factor authentication where possible. Process:
Authentication service settings were assessed
It was confirmed that strong two-factor authentication is used
Positive
Assess password recovery mechanisms. Process:
Password recovery was requested for a test user
It was checked whether a link to recover the password was successfully delivered to this user
Password was recovered using a link received from the authentication service
Positive
Lack of transport encryption
Assess the solution to determine the use of encrypted communication between devices and between devices and the internet. Process:
Transport protocols usage was assessed
It was confirmed that TLS protocol is always used
Positive
Assess the solution to determine whether accepted encryption practices are used and whether proprietary protocols are avoided. Process:
It was confirmed that only not proprietary security mechanisms are used
It was confirmed that most up-to-date versions of these protocols are used
Positive
Insecure cloud interface
Assess the cloud interfaces for security vulnerabilities (e.g. API interfaces and cloud-based web interfaces). Process:
Management system API was assessed
It was confirmed that authentication and authorization are required to make any changes in the system through the API
Positive
Assess the cloud-based web interface to ensure it disallows weak passwords. Process:
Positive
Try to type in a weak password on sign-up screen
User’s request is denied by the application
There is no possibility to use a weak password in the system
Assess the cloud-based web interface to ensure it includes an account lockout mechanism. Process:
Positive
Try to log in with a wrong password for 10 times
User account gets blocked
There is no possibility to log in without prior confirmation of identity via email
Assess the cloud-based web interface to determine whether two-factor authentication is used. Process:
Positive
Authentication service settings were assessed
It was confirmed that strong two-factor authentication is used
Assess all cloud interfaces to ensure transport encryption is used. Process:
Positive
Transport protocols usage was assessed
It was confirmed that TLS protocol is always used
Insecure mobile interface
Assess the mobile interface to ensure it disallows weak passwords. Process:
Try to type in a weak password on sign-up screen
User’s request is denied by the application
There is no possibility to use a weak password in the system
Positive
Assess the mobile interface to ensure it includes an account lockout mechanism. Process:
Try to log in with a wrong password for 10 times
User account gets blocked
There is no possibility to log in without prior confirmation of identity via email
Positive
Assess the mobile interface to determine whether it implements two-factor authentication. Process:
Authentication service settings were assessed
It was confirmed that strong two-factor authentication is used
Positive
Assess the mobile interface to determine whether it uses transport encryption. Process:
Transport protocols usage was assessed
It was confirmed that TLS protocol is always used
Positive
Insecure software/firmware
Assess the device to ensure it includes update capability and can be updated quickly when vulnerabilities are discovered. Process:
Implemented software update mechanisms were tested
It was confirmed that update data were delivered to the gateway
Positive
Assess the device to ensure it uses encrypted update files and that the files are transmitted using encryption. Process:
Communication channel which is used to send update packages was assessed
It was confirmed that HTTP protocol encrypted with TLS protocol is used
Positive
The data presented in the table show that the system which was implemented fulfills basic security requirements for IoT systems/devices/applications. Not all the tests proposed by the OWASP project have been executed. It is because not all of them have been relevant to the specification of the implemented system. Moreover, some of them (e.g., hardware tests) were pointless in this context, because of limitations of the system which were accepted during the design phase. In case the solution is introduced to the market, it would be necessary to address these issues to protect system users from security threats.
5 Summary and conclusions
This paper presents an application of edge-to-things computing which aims to offer a response to security threats within the Amst Homes. The presented solution focuses on locating the management system of the home IoT devices at the edge, so that the system may be controlled by the operator in the same way as current set-top-boxes are used for multimedia streaming. The network operator owns the smart home gateway, so it is in charge of security/privacy functionalities. The home automation network is, in our solution, isolated (higher layers) from the Internet, so all the communications are managed by the gateway. These communications are based on unified API, which presents the IoT devices functionalities independently from the device itself. For this, the network operator is in charge of updating constantly description of new vendors’ devices (and their unified API ontology) in the gateway, so new devices may be used and presented to the users through unified API. All these operations are performed through secure communication between the network operator’s management system and the smart home gateway.
The advantages of this solution for the network operator are related to the promotion of a new service (smart home) offered to the clients. This new service will have similar business plan as current multimedia streaming services such as VoD or IPTV. (These services are also offered by the network operator to the clients.)
The tests provided in this paper have confirmed that the implementation made from the scratch fulfills the specification. The tests have put special attention to security/privacy threats.
Acknowledgments
This research work was undertaken under the PolTur FUSE project supported by the National Centre for Research and Development (NCBiR) in Poland.
Compliance with ethical standards
Conflict of interest
We certify that there is no actual or potential conflict of interest in relation to this article.
Open AccessThis article is distributed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license, and indicate if changes were made.
