A federated architecture approach for Internet of Things security

A federated architecture approach for Internet of Things security Marco Leo Consorzio Univ. Ind. Lab. di Radiocom - RadioLabs Roma, Italy Email: [email protected]

Federica Battisti, Marco Carli, Alessandro Neri Department of Engineering Università degli Studi Roma TRE Roma, Italy Email: [email protected]; [email protected]; [email protected] Abstract— Internet of Things (IoT) refers to the capability to connect, communicate and remotely manage a large number of networked, automated devices via the Internet. IoT is becoming as part of daily life and aims to extend pervasive communication and networking anytime, anywhere with any device. In this context security requirements and architectures must be properly formulated, implemented in order to enforce the security policies during their life-cycle. This paper provides a survey and analysis of security in the area of IoT introducing an approach addressed to overcome the conventional security solutions and deploy a federated architecture for dynamic prevention, detection, diagnosis, isolation, and countermeasures against cyber attacks. Based on the analysis of the most common web services, the paper defines the security needs proposing a federated model to design an architecture for secure exchange of services in IoT paradigm.

In this scenario the basic security requirement of the IoT is in integration of security in physical layer for data acquisition, in the network layer for transmission and in applications in order to guarantee the confidentiality, integrity and authenticity of data.

Keywords— IoT; Web Services; SOAP; REST; security; federated networks, Cyber attacks.

I.

Figure 1 – Basic architectural model for IoT

INTRODUCTION

Internet of Things (IoT) refers to a concept where there are a multitude of objects interconnect to each other allowing people and objects to interact and create smart environments for transportation systems, cities, health, energy, etc., as part of the digital environment. The number of devices or "things" connected will increase continuously and some analysts believe that they will grow up to 26 billion units installed in 2020 [1]. Many of these products will be simple devices available on the consumer market with little or weak protection against most common cyber attacks. According to the vision of some authors, the architectural model of IoT can be divided into 3 layers: •

the sensing equipment in order to acquire data from the environment;

•

network for data transmission;

•

the top layer designed for applications [2].

Considering the architectural model shown in Figure 1, the security can be addressed throughout the whole information lifecycle, from the first design, up to the operational environment, according the following items: •

Embedded security: authenticity and integrity of the software installed on the device. Software must be authorized to run on the devices and has to be signed by an entity that authorized for it.

•

Access control: different policies for resource and access control can be applied. These policies can limit the privileges of device, components and applications so that they can gain access only to those resources needed to accomplish their jobs. If any component is compromised, access control ensures that the intruder has only a restricted access to other parts of the system.

•

Device authentication: when a device is turned on into the network it should authenticate itself before to begin receiving and transmitting data.

•

Firewalling: firewalls and/or packet inspection capability should be implemented for traffic control. The network appliances should take care of filtering the specific data directed to the device in order to assure the optimal use of the limited computational capabilities.

•

Updates and patches: once the device is in operation, it will start receiving patches and software updates. Human operators that have to roll out patches and devices must authenticate themselves in a way that does not consume bandwidth or impair the functional safety of the device.

Starting from industrial models where consolidated security policies are implemented and operational, such as for example in critical infrastructures where the management of these systems is complex and expensive, this paper proposes the application of analogous mechanisms in the field of home automation through an architectural design capable of being implemented even in the Home 2.0. II.

SECURITY FRAMEWORK IN IOT

IoT is going to be part of life by extending the communication and networking capabilities; its security is important for the safe and reliable operation of the connected devices. However the implementation and the deployment models for guaranteeing this multi-layer security of IoTs is still an open issue. Firewalls and protocols are able to manage the data traffic but are less effective in embedded protection of endpoints where the security usually depends by the characteristics (i.e. computational power) of each node. Additionally, as the IoT becomes a key element of the Future Internet, the provision of adequate security for the IoT infrastructure across multiple domains becomes ever more important. Security cannot be thought only as an add-on of the single device, but rather requires an integrated approach across all layers, aiming at deploying a federated environment where producers and consumers of services and information can collaborate over different administrative and application domains. At physical and acquisition level, the security must ensure, at one side, that the nodes would not be cheated, controlled or damaged and, on the other side, that information would not be distorted, faked or replied illegitimately. At the transmission level, security should guarantee the confidentiality, the integrity and the authenticity in data exchange and at application level, it has to ensure the privacy, confidentiality, as well as the safety storage of information to cover individual privacy protection, middleware safety [3], etc. Usually the management of security is carried out by means a model where users within a domain are naturally mapped to roles and access rights are associated with these roles. In literature some authors propose that the resource management is restricted to delegation only within a single domain [4,5,6]. On the other hand, IoT should be characterized by highly dynamic nodes turnover across different domains and devices have to face with the continuous changing of connectivity conditions and network topologies. The nodes may suffer, for

example, the wireless channel change, the constraints of mobility or physical factors such as the limited power that could cause the death of the device. In such scenario a dynamic and flexible design of the system access control is suitable mainly in environments where the high levels of collaboration in distributed environments need the deployment of mechanisms to distribute credentials and deputations across multiple domains. The security controls have evolved in parallel with the evolution of the network in order to try to minimize its harmful activities. An important aspect in computer security focuses on solutions to block threats that are exploiting vulnerabilities in the automation and control systems that are accessible on Internet. In IoT in fact, in addition to the standard ICT components like computing (e.g., servers, workstations), storage and networking devices (e.g., switches, routers and firewalls), cyber attacks on distributed systems can be targeted towards custom devices using, for example, programmable logic controllers (PLC) or user applications remotely accessible through IP gateways. On the other hand, the wide spread of sensors and actuators with autonomous processing and communication capabilities, compliant with the IoT paradigm, will increase the exposure of objects to cyber attacks. An example, in field of the industrial automation, there are bodies as the Industrial Control Systems Cyber Emergency Response Team (ICS-CERT), that operates within the National Cybersecurity and Integration Center (NCCIC) as division of the Department of Homeland Security's Office of Cybersecurity and Communications in USA, that collects reports on incidents that resulted from weak network configuration and/or lack of perimeter security [7]. The vulnerabilities addressed by ICS-CERT are relevant also in IoT context and search engines such as SHODAN [8], ERIPP (Every Routable IP Project) or Google enable researchers and attackers to easily discover and identify devices detectable on public networks, and then to exploit their vulnerabilities. Solutions for security in IoT have been presented in some papers addressing the problem of designing dynamic delegation methods in distributed and multi-domain environments [9,10]. These papers are focused on dynamic authorization and on the delegation chain in federated secure framework by exploiting the mechanisms of issuing a token and asserting it into an authorization document. In IoT, the devices, interconnected across heterogeneous networks, may belong to different classes: • • • • • •

different vendors; of different dates and release versions; of different capabilities and complexity; of different bitrate; using different technical interfaces; designed for different functions.

Devices in the IoT are sometimes called “Smart Devices”, though groups of devices need not to be equally smart. A gateway device is the element able to mediate the communication among federated nodes filtering, aggregating

and formatting data from a group of simple sensors before sending them somewhere else. In this scenario the Secure Mediation Gateway (SMGW)[12] is introduced as the network element able to: • discover domain status information; • overcome heterogeneity; • provide secure communications among IoT nodes. Adopting this approach we can partition the “things” in two groups. The first one, denoted in the following as the intraSMGW group, is the internal set of things belonging to a security domain accessible on by a single SMGW. The second group is constituted by the remaining "things". Over the SMGW there is a federated network of SMGWs, called interSMGWs, enabling the secure remote access to things within a domain supervised by a single SMGW. So the SMGW is the boundary element between intradomain and interdomain devoted to allow the secure data exchange by means of a federated network of SMGWs. In addition, the SMGW is also the element that can enable the remote secure access to remote devices by means a crypto engine software implementing a public key encryption scheme as well as a digital signature scheme. Remote devices, including smartphones and tablets, can address directly a “thing” within the intraSMGW domain by using a secure end-to-end link on the SMGW itself. III.

SERVICE SCENARIOS: SMART DOMOTIC ENVIRONMENT

Smart homes are a natural scenario to apply the IoT model in practice improving the concept of smart domotic environments. In future, the home environment embedded sensors and actuators (e.g., in consumer electronic products and systems) will be self-configured and remotely controlled over Internet. These devices will sense and monitor the user activities, predicting the future behaviour and preparing the environment according to the user’s preference or needs in order to provide the most convenience, comfort, efficiency and security.

Figure 2 – A typical scenario for Smart Domotic Environment In a domotic scenario we consider the role of the Secure Mediation GateWay (SMGW) that shall enable the communication among IoTs providing: • the collection of home sensing data by means of specific adapters attached to IoTs;

• the storage of metadata provided by local IoTs in a dedicated database; • the interface with a monitoring tool for supplying information necessary for forecasting (event, alarms, etc.); • the discovery and retrieve services in order to relate the remote systems through a secure communication with other remote GWs Home on behalf of the security policies; • the delivery of metadata provided by the forecast tools (e.g., current status and expected home automation system) to authorized subscribers (e.g. Home GWs others); • the management of security policies; • the application of AAA rules; • the application of encryption/decryption and signature/authentication mechanisms for inbound and outbound traffic. As a general approach, the SMGW should enable the deployment of different security configurations where an element, that provides and exploits information within an area network, can belong both to the same domain identified with a SMGW or can be located under a different administrative domain. This introduces the identification of the already defined macrodomains: intraSMGW and interSMGW. The intraSMGW refers to the capabilities to enable the publication and consumption of data and services for a set of things directly connected to the same SMGW. Instead, the interSMGW refers to the capabilities to exchange data and services across different SMGWs. The security services provided by the SMGW include the authentication, authorization, confidentiality, and integrity for: • publication and subscription of services in intraSMGW and interSMGW domains; • communications among entities within a local Domain where the frontend towards federated entities is the SMGW; • communications among different SMGWs. A security domain is a set of local domains with a SMGW as front-end. Each SMGW is under the control of a security administrator that, by means of a management tool, can set and share common security policies for user authentication and authorization. Therefore, the SMGW provides a secure interface for exchanging IoT status information among federated domains focusing on: • provisioning of a common secure communication framework; • publication and discovery of events generated by IoTs in order to propagate the information to trusted interdependent SMGWs; • enabling the extension of risk prediction from single SMGW to multiple interdependent SMGWs. IV.

WEB SERVICES AND SECURITY APPROACH FOR IOT

The design of the architecture has been inspired to the Service Oriented Architecture (SOA) and, from an architectural point of view, traditional SOA systems can be based on a set of characteristics such as:

use of specific protocols in order to enable missioncritical service capabilities; • use of (Web) Services to enable capabilities according to the requirements (best effort, real time, etc.). This architecture model does not impose constraints in the underlying domain and the design of components has been focused on maximizing decoupling among each subcomponent by conveniently using two protocols: • SOAP Web services for mission critical message exchange; • REST services for light communications of IoTs with low capabilities (small CPU, memory, ect.) . The majority of SOAP-based services rely on HTTP as the transport protocol. The SOAP HTTP services use only a small subset of the HTTP specifications, restricted mainly to the POST or GET methods. Additionally SOAP introduces an overhead increasing the consumption of available bandwidth and making this protocol less attractive for applications relying of low bit rate communication links as well as for time critical applications. The WSDL is the format able to describe the capabilities of a service, such as the messages that it can send and receive, and share the knowledge of services. In large SOA scenarios, involving hundreds of services and clients, the level of service-client dependency should be carefully designed to avoid serious service-management problems. Entities can communicate through the exchange of messages and the information delivery can be synchronous, asynchronous, or a combination of the two. In particular, asynchronous communications enable the message delivery in a loosely-coupled and autonomous fashion in order to overcome network failures. Applications that communicate through a publish/subscribe paradigm require that the sending applications (publishers) publish the messages without explicit specification of the recipients or having awareness of intended recipients. Similarly, receiving applications (subscribers) must receive only those messages that the subscriber has registered an interest in. The integrity and confidentiality of messages and of the identity of the participating parties must be guaranteed. The Web Services Security Language (WS-Security), is the base for the implementation of a wide range of security solutions. The Organization for the Advancement of Structured Information Standards (OASIS) ratified WS-Security as a standard under the name OASIS Web Services Security (WSS) and signing and encryption of SOAP messages as well as the propagation of security tokens are mechanisms supported by WS-Security. WS-Security leverages the XML Signature and XML Encryption standards by the W3C. The OASIS WS-Security standard specifies how to extend the SOAP message header in order to achieve message integrity, confidentiality, authentication of originator and replay protection. It is based on the use of the security standards XML Digital Signature and XML Encryption and supports several security token formats (e.g. X.509, SAML). Adopting this approach, the SOAP message either contains the information needed to secure the message or it contains information about where to get that information to handle •

security needs. The SOAP message also contains information relevant to the protocols and procedures for processing the specified message-level security and, because the security information is part of the message, it is independent of a transport protocol and the related security, such as for example HTTPS. The client adds to the SOAP message header security information that applies to that particular message. When the message is received, the Web service endpoint, using the security information in the header, verifies the secured message and validates it against the policy. The communication pattern using publish/subscribe is particularly suitable to situations where information is produced at irregular intervals. At present, there are two standardization efforts regarding publish/subscribe for WS: OASIS finished its Web Services Notification (WSN) standard late in 2006, whereas W3C has produced later a version of a similar framework called Web Services Eventing (WS-Eventing) [11]. The WS-Eventing specification defines a baseline set of operations that allows WS to provide asynchronous notifications to interested parties. A Message Broker implements the WS-Eventing model. The support to REST services completes the set of service interfaces available and, while SOAP is introduced mainly to support the security requirements in the publication and consuming of services in interSMGWs scenarios, REST revolves the concept of consuming the resources taking advantage of HTTP features. Basically REST-enabled systems are modelled in terms of URI-addressable resources that can be accessed through HTTP stateless interactions. Following the principles of REST, we can design scalable services that truly exploits Web principles while being more efficient in terms of both the network bandwidth utilized and of the round-trip latency incurred during these requests. The use of SOAP or REST depends on the interface provided by the specific information hub. V.

SMGW MODEL FOR IOT IN DOMOTIC ENVIRONMENT

According to the considerations presented in the previous sections, an architectural model form the SMGW must be able to: • discover all the distributed information that are relevant for the alerting system; • overcome the heterogeneity; • exchange information that are related to devices, applications and services with heterogeneous capabilities across different domains over Internet in a secure way. The elements of the architecture provide the following basic features: • management of storage and retrieval of data/metadata in local DB; • auditing engine to perform SMGW monitoring and login order to support forensic analysis; • event management for: o subscribe and receive the messages published by remote nodes organized in topics; o publish the local metadata organized by topic, through the message broker;

subscription service register containing the list of all the services to which the SMGW is subscribed; o WS-Security to implement the Web Service Security stack; o Firewall & IDS to Implement the mechanisms in order to secure the inbound/outbound communications; o WS-Eventing for publish/subscribe of messages towards remote nodes; • SMGW management for administration, operation and maintenance operations; • Identity server for AAA policy decision point and security token service. Figure 3 shows a scheme of the proposed architectural model. o

communication both for intraSGMW nodes and for interSMGW. The proposed federated architectural model has been designed under the assumption that the IoT space can be divided into the intraSMGW and interSMGW categories. This architecture promotes the management of the security by using the SOA approach based on Web Services. It supports the use of SOAP and REST principles according the features and nature of devices and services. In this scenario, the SMGW has in charge the management of all security features from the simple accounts management up to the availability of a crypto engine to support the secure remote access to the thing within the SMGW domain. The security of the services interSMGW is managed by means of WS-Security approach by using a Message Broker. The domain of devices contains heterogeneous communication technologies (and related security solutions) and the proposed model is designed to overcome the security problems in exchanging of data over different domains. Currently, the researches on IoT safety are still in progress and the security mechanisms are not perfect. As future work, the protocol description and security management can be further evolved considering the usage of crypto engines.

[1]

Figure 3 – SMGW model architecture for Smart Domotic Environment For the interSMGW data exchange, a SMGW Web Service client has in charge of publishing data by means of WSEventing brokered message. The message broker is able to send data to remote subscriber SMGWs through the WSSecurity stack, which assures transmission security. On the remote side, the SMGW WS server receives the messages delivered by the broker and store them in a local data repository. VI.

CONCLUSIONS

The design of federated architecture able to exchange data and services in IoT scenarios has impact on development of the application of the IoT. The proposed architecture model is mainly devoted to deploy and manage a federated environment for authority delegation mechanism, identitybased capability and dynamic context information. The key element is the SMGW that is dedicated to manage the secure

Gartner Inc - "Forecast: The Internet of Things, Worldwide, 2013." – December 2013 [2] Li, Lan. “Study on Security Architecture in the Internet of Things.” In 2012 International Conference on Measurement, Information and Control (MIC), 1:374–77, 2012. doi:10.1109/MIC.2012.6273274. [3] C. M. Medaglia, A. Serbanati - An Overview of Privacy and Security Issues in the Internet of Things - 20th Tyrrhenian Workshop on Digital Communications - 2010, Springer New York, pp 389-395 - DOI 10.1007/978-1-4419-1674-7_38 [4] E. Barka and R. Sandhu. A Role-based Delegation Model and Some Extensions. Proceedings of the 23rd National Information Systems Security Conference, pp.101-114, 2000. [5] E. Barka and R. Sandhu. Role-Based Delegation Model/Hierarchical Roles, Proceedings of the 20th Annual Computer Security Applications Conference (ACSAC ’04) pp.396-404, 2004 [6] V. Atluri and J. Warner. Supporting conditional delegation in secure work ow management systems, Proceedings of the 10th ACM Symposium on Access Control Models and Technologies (SACMAT'05) , pp.49-58, 2005. [7] https://ics-cert.us-cert.gov/sites/default/files/Monitors/ICSCERT_Monitor_%2520Jan-April2014.pdf [8] http://www.shodanhq.com/ [9] H. Gomi, M. Hatakeyama, S. Hosono, and S. Fujita, “A delegation framework for federated identity management,” in Proceedings of the 2005 workshop on Digital identity management , ser. DIM ’05. ACM, 2005, pp. 94–103. [10] H. Gomi, “Dynamic identity delegation using access tokens in federated environments,” in Web Services (ICWS), 2011 IEEE International Conference on july 2011, pp. 612 –619. [11] http://www.w3.org/TR/ws-eventing/ [12] M. Castrucci, A. Neri, F. Caldeira, J. Aubert, D. Khadraoui, M. Aubigny, C. Harpes, P. Simões, V. Suraci, P. Capodieci,”Design and implementation of a mediation system enabling secure communication among Critical Infrastructures.”, International Journal Of Critical Infrastructure Protection, vol. 5, p. 86-97, 2012