internet of things (Iot) technical overview€¦ · (IOT) TECHNICAL OVERVIEW CUSTOM SOFTWARE DEVELOPMENT . This document is the sole property of bitHeads Inc, and may not be reproduced,

INTERNET OF THINGS (IOT) TECHNICAL

OVERVIEW

CUSTOM SOFTWARE DEVELOPMENT

This document is the sole property of bitHeads Inc, and may not be reproduced, copied,

projected, defaced, edited or used in any way without the written permission from bitHeads Inc. 1

IoT Components & Architecture The main factor in enabling communication between these diverse “Things” is standardization. Though standardization can be easily claimed in a research environment, it can be very difficult to achieve in the real world. High-level reference architectures are therefore a great help for standardization, as they define guidelines that can be used to implement the proper planning of an IoT system. However, sometimes these high-level reference architectures are difficult to understand because they can be extremely abstract and sometimes very difficult to show customers in the industry. Therefore, the following sections will lay out a set of guidelines to substantiate a more concrete architecture, to show the complete life-cycle down to the implementation of an actual system within the IoT. There is a certain amount of core IoT components that you will find in every IoT reference architecture, including:

• Interoperability and integration components towards things and devices. • Context aware computing techniques such as the definition of a context-and

action-model. • Security guidelines that range over the complete architecture.

Current IoT architecture can be seen as a larger-scale version of Anind K. Dey’s context toolkit. Designed no an application level, the context toolkit is designed for Geographical Information Systems (GIS). In the IoT we have to extend the context toolkit towards things intercommunicating between each other. This results in the basic idea of a goal, context information and actions remaining in the IoT world (ie. Context Information + Goal(s) = Action(s)). In the IoT space, goals are not only defined on the user level (ie. by application), but things themselves can work towards certain goals without actively including the user. Devices will serve the user but they will act autonomously in the background, lending idea to the concept of ubiquitous computing. The term “context” defines the state of an environment (usually the user’s environment) in a certain place and time. The context model distinguishes between context elements and context situation. Context elements define specific context, usually on the device level. A context element can be, for example, a temperature value at a certain time and location.



Figure 1 - Context Model The context situation is differed from context elements, in that it is more aggregation focused. In order to let a “thing” know if it can actually communicate with another “thing, a certain communication standard has to be agreed on. The context situation model defines what the “thing” is capable of in ways of context. Whenever a context situation is given to a “thing, the “thing” evaluates if an action is to be triggered according to its defined goals. Thus, depending on the context, Context situations is generally a view on the environment in a certain location at a certain time.

Figure 2 – Context Situation Model



Reference IoT Layered Architecture (RILA) In the IoT context, RILA acts between things, devices and the user. The following image provides a high-level overview of the RILA.

Figure 3 – Reference IoT Layered Architecture (RILA)



RILA consists of six layers: Two “cross-section layers”, namely “Security” and “Management”, run beside these layers and affects each of these layers.

Figure 4 – RILA Layer Architecture

RILA Layers Breakdown The six RILA layers consist of:

• Device Integration Layer • Device Management • Data Management • Context Management • Thing Integration • Application Integration Layer

Device Integration Layer: Connects all the different device types and consumes device measurements as well as communicating actions on the device level. This layer can be seen as a translator that speaks numerous languages. The output of the sensors and tags, as well as the input of the actuators, both depend on the protocol being implemented. This layer consists of three main components:

1. The driver component, which is also the lowermost component, communicates with all the different sensors, tag and actuators on low level, vendor specific, communication protocols. It contains driver instances for every type of low level device known to the system.



2. The device discovery component, which is triggered by two events. One of the events is from the device management layer, which tells this component to add a new device. The other event is run by the driver component, which notifies this component in case a new device is added. The device discovery component also handles deregistration of devices.

3. The final component is the device communication component. It is the bridge between the device management layer and the driver component. This component decides which driver is called when the device management layer addresses a device.

Figure 5 – Device Integration Layer Device Management Layer: In charge of taking device registrations and sensor-measurements from the device integration layer. Furthermore, it communicates status changes for actuators down to the device integration layer. The device integration layer validates the status chance, to make sure it conforms with the actuator and then translates the status change to the actuator. In essence, this layer is in control of the devices in the way that it knows which devices are connected to the system. Each change to a device’s registration as well as incoming measurement data has to be communicated from the device integration layer to the device management layer, so information can be updated and stored.



Figure 6 – Device Management Layer Data Management Layer: Seen as a central database that holds all data of a “thing”, which is capable of only one possible implementation. For larger things within the system, data management might be a data warehouse or even a complete data farm. The implementation of this layer depends strongly on the use-case for the specific thing.

Figure 7 – Data Management Layer



Context Management Layer: Defines the central business logic within the RILA and is responsible for six main tasks.

1. Define the goals of the “thing”. 2. Consume the context situation(s) of other “things”. 3. Produce the (own) context situation of the “thing”. 4. Evaluate the (own) context situation towards the goal. 5. Trigger actions that help to fulfill the goal according to the evaluated rules. 6. Publish context situations for other things.

Figure 8 – Context Management Layer

Thing Integration Layer: Responsible for finding other “things” and communicating with them. Once two “things” found each other they have to undergo a registration mechanism. The “thing” integration layer has to evaluate if the communication with the “thing” to be partnered with is possible. Due to this, the context situation and/or action schemata must be compared, both of which are provided by the context management layer. The “thing” registration can be done in a central component or by the “thing” itself (ie. Auto-discovery network scan).



Figure 9 – Thing Integration Layer Application Integration Layer: Connects the user to the “thing”. Applications that are built on top of the RILA architecture are located here. The application integration is a service layer, or even as a simple UI on top of the stack. The various implementations of the layer depend on the use case.

Figure 10 – Application Integration Layer



Cross-Layer Challenges and Security When building an IoT system, one needs to consider security on all the layers comprising of the RILA architecture. Attack vectors need to be recognised to identify appropriate security standards.

Figure 11 – Cross-Layer Security Architecture

Attack Vectors These are the attack vectors that can be identified:

1. User – The end user is a possible attack vector because it can affect the system either on purpose or without its knowledge. One common type of this attack is known as phishing, where the attacker attempts to acquire sensitive information from the victim.

2. Web Interface – If the application offers a web interface, it can be subjected to “conventional” attacks like SQL injections or DDOS attacks.

3. Thing – Smart devices often communicate with an external system via an application, which relies on a form of operating system. The two main liabilities are the app itself which might not offer sufficient security mechanisms of the operating system underneath that could be hacked or infected.



4. Low-level Hardware Components – One must take into consideration computing

power when considering hardware components and the security they provide. The main liability is represented by low power devices that simply do not have the required CPU power for secure encrypted communication. Working with multiple sensors can potentially eliminate the outliers to get an accurate picture but security cannot be achieved. If correctness of data provided by the sensors is essential, the more powerful the hardware is required, increasing the cost of acquisition by a significant margin.

5. Communication channels – Securing the communication channel depends not he protocol used. There are three main protocols that are relevant for IoT and securing their communication.

a. RFID and NFC: Communication between tag and reader is wireless and can easily be eavesdropped, making data encryption essential. When writing data to a new tag, default authentication keys should be changed, since the key management for the tags is done by the system that controls the reader. RFID tags are very diverse, and security must be considered when acquiring them.

b. Zigbee: The communication channel between a Zigbee (an IEEE 802.15.5-based specification for a suite of high-level communication protocols used to create personal area networks and designed for small scale projects which need wireless connection) device and the application is secure because the encryption algorithm is AES-128. Though the initial key exchange must be considered insecure, when a new device is added to the network, the key is send to the device in plain text and can be found by sniffing, given the proper timing.

c. Thread: The communication between two Thread devices is secured by an AES encryption. The establishment between a new device and the application is done in a secure way using a key exchange algorithm.

Attack vectors can be grouped into more technical attack vectors that target specific components of the system. These can range from:

• Authentication • Authorization • Authenticity validation: signature for messages • Key exchange mechanisms • Encryption • Configurations – can pose a security threat from bad to default configurations • Third party libraries – may contain security breaches and well-known exploits

when not updated • Network Security



The dilemma of choosing the right amount of security per various use cases can be shown via the security-triangle. The triangle represents a compromise that occurs in every day use case. You can only choose one point inside the triangle that represents what you want or need in terms of security, cost and business requirements. Finding the appropriate security measures is always a difficult situation, as business situations and costs often contradict with high security measures. From the security-triangle, the further away from a specific vertex, the lower the need for that specific area. For example, if you were sitting at the business requirement vertex, all the resources would be concentrated on that area and less towards technical capability and security requirements.

Figure 12 – Security-Triangle Model

Conclusion This paper provides a quick introduction and overview of the architecture pertaining to the Internet of Things (IoT), helping to break down the IoT world to a more comprehensible level from both a high-level concept perspective to a lower-level framework. Context aware computing techniques help to make certain parts of this world more understandable. Using the conceptual models, and understanding the security components involved can vastly help organizations to upgrade their existing legacy systems into the modern technological era. With the quick adoption of IoT and its practices, along with the inevitable rise of its use cases in enterprise scenarios, it is important to grasp and implement these concepts quickly to not only understand the intricacies involved in this new technology, but to recognize the value of utilizing these applications to stay two steps ahead of the competition in this ever-increasing world of both user and system connectivity.

Documents

internet of things (Iot) technical overview€¦ · (IOT) TECHNICAL OVERVIEW CUSTOM SOFTWARE DEVELOPMENT . This document is the sole property of bitHeads Inc, and may not be reproduced,