ABSTRACT
The Internet of Things (IoT) is a recent trend that extends the boundary of the Internet to include a wide variety of computing devices. Connecting many stand-alone IoT systems through the Internet introduces many challenges, with security being front-and-center since much of the collected information will be exposed to a wide and often unknown audience. Unfortunately, due to the intrinsic capability limits of low-end IoT devices, which account for a majority of the IoT end hosts, many traditional security methods cannot be applied to secure IoT systems, which open a door for attacks and exploits directed both against IoT services and the broader Internet.
This paper addresses this issue by introducing a unified IoT framework based on the Mobility First future Internet architecture that explicitly focuses on supporting security for the IoT. Our design integrates local IoT systems into the global Internet without losing usability, inter-operability and security protection. Specifically, we introduced an IoT middleware layer that connects heterogeneous hardware in local IoT systems to the global Mobility First network. We propose an IoT name resolution service (IoT-NRS) as a core component of the middle ware layer, and develop a lightweight keying protocol that establishes trust between an IoT device and the IoT-NRS.
SURVEY OF THE EVOLUTION OF IOT ARCHITECTURES
Figure 1. Legacy Internet of Things (IoT) architectures
Many current IoT designs do not support applications seamlessly. Historically, stand-alone IoT systems were proprietary implementations, such as DF-1, MelsecNet, Smart Distributed System (SDS), and BACnet. These fragmented solutions were typically integrated vertically and characterized as “silo” solutions, as shown in Figure 1a. A large number of independent legacy IoT systems co-exist across the Internet. However, their “silo” nature conflicts with the open spirit of the Internet and hence introduces problems of inter-operability and service-level interaction, which limits the benefits of IoT systems and could impede large-scale IoT deployment.
GENERAL SECURITY ANALYSIS OF IOT SYSTEMS
Figure 2. Potential threats for the IoT systems
The IoT extends the Internet to the physical world and thus poses many new security and privacy challenges. Some of the problems are due to the intrinsic characteristics of the IoT and its differences compared to traditional networks, while others arise as a result of the integration of the IoT and the Internet. As shown in Figure 2, various adversaries may come in at different points to attack IoT systems. To protect against those attacks, it is important to examine the security problems according to the information flows and potential adversarial points of control.
MOBILITY FIRST-BASED IOT ARCHITECTURE
Figure 3. The protocol stack of the MobilityFirst architecture
Figure 3 shows that MobilityFirst introduces a new protocol stack and replaces the original “narrow waist” of the current Internet (i.e., TCP/IP) with a new name-based service layer, which consists of the Name Certificate & Resolution Service (NCRS) and the Global Name Resolution Service (GNRS). This new service layer is centered on the concept of “flat” security-based GUIDs for network objects, a single abstraction that serves as both the network object’s identity and the public key. Various types of network entities, e.g., a smartphone, a person, a group of IoT devices, a piece of content or context, can obtain their globally unique identifiers from the NCRS, which provides translation services between human readable names and public-key based globally unique identifiers.
Figure 5. MobilityFirst-based unified IoT architecture
Figure 5 explains how the IoT architecture works with the support of the MobilityFirst infrastructure. The aggregator collects data and then the LSG sends the aggregated data to the storage location. The raw data might be processed by the LSG for context refining/aggregating purposes. Meanwhile, the LSG publishes the data information, which contains a data GUID, the access control policy and the storage location information (e.g., human readable names or network address), to the IoT server so that end users may query the IoT server about where to fetch the data. The IoT server may decide how to enforce the access control policy: either at itself or push it to the NCRS/GNRS. The data consumer, typically an application, first makes a query at the IoT server for data information through its edge router and then fetches the data from the storage location or the aggregator directly.
IOT MIDDLEWARE SECURITY
Figure 7. Three-tier name resolution framework of the Mobility First-based IoT architecture
On the other side, in order to smoothly integrate the local IoT system into the global Mobility First network and take advantage of the rich network services provided by Mobility First, it is necessary to maintain use of the GUID in the scope of the broader global network so that data consumers can contact IoT devices or retrieve/subscribe IoT data with the corresponding GUIDs.
In order to reconcile the conflicts of the two different cryptographic schemes (used in two different scopes), integrating an IoT name resolution service (shown in Figure 7) in the middleware to handle naming-related issues is the best solution as it keeps a clean separation between the underlying network infrastructure and the IoT system. The IoT name resolution service (IoT-NRS) bridges the gap between different cryptographic schemes used in the local IoT network and the global Internet. This design makes IoT systems flexible, extensible and easy to manage.
DELEGATION-BASED KEY PROVISIONING PROTOCOL
Figure 8. The block diagram illustrates the framework of the delegation-based key provisioning protocol
The block diagram illustrates the framework of the delegation-based key provisioning protocol: Child device is an edge IoT device who wants to join the IoT system and establish a membership key with the Guardian device; Guardian device is the group authority of the local IoT network, who contacts Parent device to verify Child device and obtains authorization; Parent device has a pre-existing trust relationship with Child device in terms of the Parent key, and provides verification/delegation to the Guardian device so that Guardian device and Child device can reach a resultant key agreement: membership key.
Figure 10. Modularized prototype framework design: the framework includes three major modules
Figure 10 shows the modularized prototype framework design. Each party’s protocol package includes three major components: Instance Manager, Protocol Manager and Utility Functions. Each party should be able to work independently to perform tasks, such as receive messages, parse messages, perform designated computations, construct messages and send messages. In the protocol system model, there are two client/server based communication channels. For the channel between the Guardian and the Child, the Guardian serves as the “server”, while the Child is the “client”. On the other channel between the Parent and the Guardian, the Parent serves as the “sever” while the Guardian is the “client”.
CONCLUSIONS
In this paper, we first investigated existing IoT solutions and analyzed their disadvantages. We focused in depth on security aspects of the various IoT architectures. Starting with a general security analysis, we identified security and privacy concerns unique to IoT systems. Then we proposed a unified IoT architecture design based on the MobilityFirst network that addresses security concerns and increases confidence about the assurable operation of the Internet of Things. We introduced a new layer in the architecture, which we refer to as the IoT middleware, that connects heterogeneous hardware in local IoT systems to the global MobilityFirst network.
One of the core components of the IoT middleware is the IoT-NRS (IoT name resolution service), which is a device registration service that provides naming and key management. Further, we developed a delegation-based key provisioning protocol that establishes a long-term membership key between an IoT device and the IoT-NRS, with the assistance of a trusted third party. The protocol is specifically designed to be trustworthy while also being lightweight. Moreover, this protocol can support many functions that might be expected in IoT systems, such as ownership transfer, or establishment of an attestation key. Our efforts extend the Internet to include the real world objects and therefore facilitates the formation of a large and new network inclusive of embedded devices.
Source: Rutgers University
Authors: Xiruo Liu | Meiyuan Zhao | Sugang Li | Feixiong Zhang | Wade Trappe