Towards Secure Middleware for Embedded Peer-to-Peer Systems: Objectives & Requirements

Transcription

1 Michele Albano Antonio Brogi Razvan Popescu Manuel Díaz José A. Dianes Towards Secure Middleware for Embedded Peer-to-Peer Systems: Objectives & Requirements Received: June 1st, 2007 / Accepted: July 2nd, 2007 Abstract The development of next generation Embedded Peer-To-Peer Systems raises a number of challenging issues for pervasive computing. In this paper we overview the objectives of the ongoing European SMEPP (Secure Middleware for Embedded Peer-To-Peer) project. In particular we discuss different types of requirements that have been identified in SMEPP. Keywords Embedded Peer-to-Peer Systems Secure Middleware 1 Introduction P2P systems are distributed computing systems where all network elements act both as service consumers (clients) and service providers (servers). Moreover, most of the mechanisms of communication are not based on preexisting infrastructures, but rather on dynamic ad-hoc networks among peers[1]. Embedded Peer-to-Peer Systems (EP2P)[2] represent a new challenge in the development of software for distributed systems. An EP2P is a P2P system where small, low-powered, low-cost embedded systems collaborate in the processing and management of information using wireless channels. EP2P systems are flexible enough to be applied in diverse areas, such as: Environmental monitoring. Monitoring of the effects of industrial plants on the environment is a key issue in different application domains and particularly in the field of nuclear energy[3]. The use of EP2P opens up new perspectives that allow monitoring in the case This work has been partially supported by the SMEPP project (EU-FP6-IST ). M. Albano, A. Brogi, R. Popescu Department of Computer Science, University of Pisa, Italy M. Díaz, J. A. Dianes Dpt. of Languages and Computer Science, University of Málaga, Spain of small leaks during inspection or even in the case of accidents where no other equipment is available. Home systems. A smart house is usually made up of several intelligent devices that can control home appliances or feel their surroundings[4]. EP2P systems can help both in the unobtrusive management of the smart house (from anywhere, to anywhere) and in the collaboration between the embedded devices of the house (e.g., switch off the air conditioning if nobody is in the room). Mobile telephony. The features of new programmable mobile phones make them real execution platforms, supporting multitasking and real-time operating systems and ubiquitous connectivity. With specific problems such as high latency, reduced bandwidth, and dependency on batteries, mobile phones are an interesting field for developing new applications such as network games or mobile sensor applications[7]. The potential advantages of EP2P are adaptability, scalability, high availability, and ubiquity, as the model is based on the possibility of incorporating and removing resources in a dynamic and adaptive way, and users should be able to access those resources offered by the network anytime, anywhere. The main drawbacks are also due to these characteristics. EP2Ps present a high degree of heterogeneity (applications may run on different devices, from PDAs to sensor network nodes, with quite different network bandwidths and computing power) and autonomy (the elements enter the system and exit in an independent way, causing frequent reorganizations of the systems). These drawbacks raise important technological challenges such as decentralization, links with transient communications (connections and disconnections happen in an unpredictable and frequent manner), and a constantly changing topology. In addition, there is a major problem that any EP2P system must deal with: Security. Traditional P2P systems have to face attacks on the routing protocols, attacks against the identity of the nodes, and threats against

2 the confidentiality, integrity and authentication of the information that is contained into or is circulating in the network[5]. In an EP2P context, these problems are much more troublesome, because the underlying architecture is much more vulnerable than that of traditional P2P systems due to resource constraints (low battery, low processing power), lack of tamper-resistant packaging, and the nature of open and public communication channels. Besides this high degree of vulnerability, state of the art security techniques are not easily adaptable to P2P environments since there are no centralized servers with security databases that can provide typical services such as authentication and authorization. In a serverless peer environment, the peers must provide their own authentication. A structured middleware can be able to cope with the complexity of this scenario, and can provide the necessary abstractions for the definition, creation and maintenance of applications. The paper is organized as follows. Section 2 presents the general requirements that have been identified for SMEPP. Section 3 discusses detailed requirements for the architecture of SMEPP middleware. Conclusions and final remarks are presented in Section 4. 2 General SMEPP Requirements One of the key factors for the success of EP2P systems is the possibility of abstracting EP2P-related problems by means of convenient middleware. The Secure Middleware for Embedded Peer-To-Peer (SMEPP) project aims to create a novel middleware in order to reduce the level of complexity that is felt by the final architects and developers. Without middleware (including formal tools and methodologies), the definition, creation and maintenance of an application would be a nearly impossible task, having to face in every prototype the EP2P problems from scratch. A convenient middleware may hide the complexity of the underlying infrastructure while providing open interfaces to third parties for secure application development. The development of such a middleware is challenging, since besides the disappearance of the roles of client and server, which are the basis of the most extensively used generic middleware (CORBA, J2EE,.NET), other critical requirements appear, which have to be supported by these infrastructures (mobility, new security problems, identification and discovery and localization protocols, new quality of software criteria, etc). The main objective of the SMEPP project is to develop a new middleware, based on a new network centric abstract model, specially designed for EP2P scenarios, trying to overcome the main problems of existing proposals for domain specific middleware for EP2P. The middleware will have to be secure, generic and highly customizable, allowing for its adaptation to different devices (from PDAs and new generation mobile phones to embedded sensor actuator systems) and domains (from critical systems to consumer entertainment or communication). In order to achieve these general objectives, the project research efforts and specific project objectives have been organized into four main classes that are briefly discussed in the following sub-sections. 2.1 Service and Interaction Model The high degree of self-configuration and self-management required in EP2P has a significant drawback. Each peer must be programmed in such a way to be able to autonomously manage, at run time, its interactions and interconnections with its environment. From the point of view of the developer of an EP2P application, this means that she is responsible for programming the interaction among the peers. The current approach is to program these aspects exploiting protocols provided by underlying infrastructures such as JXTA[6] or the Microsoft P2P framework[8]. Programming the interaction among peers using these low-level protocols is not an easy task due to the dynamicity of the network. The aim is to provide a serviceoriented abstract model to program the interaction among peers, which hides low-level details to be treated by the support infrastructure. Two key aspects of the model involve: Groups, that are the way peers are organized into sets. Services, that are the way a peer allows other peers to interact with itself. In particular, the model dictates that security is bound to groups and that a peer can publish and invoke services in the groups it has joined. 2.2 Middleware Architecture and Infrastructure Traditional middleware architectures have focused on achieving interoperability across heterogeneous platforms and software languages. Although the platforms have evolved from their creation incorporating new specific services and profiles (real time, embedded systems, telecommunications), their architectures have remained, to a great extent, stable. The need to provide support for the new interaction models and the nature of the requirements of EP2P represent a challenge for defining new middleware architectures. These architectures must provide most of the services provided by current architectures and be open and extensible enough in order to support the quick evolution of devices and technologies in this field. The main objective of the SMEPP project in this area is the

3 definition of a new middleware architecture specific for EP2P systems. Besides keeping the goals present in other generic P2P systems, such as interoperability and heterogeneity support and the capability of information sharing, EP2P systems must take into account new aspects such as the surveillance of application behaviour, the processing infrastructure and the underlying communication networks, in order to achieve the appropriate quality of service. The complexity of these tasks and the need for adaptation to different devices and domains make it necessary to establish a component based software architecture or, in fact, a software architecture family[9]. Although there has been much work done on component based reconfigurable middleware systems, they do not deal specifically with EP2P systems and SMEPP will develop a specific Component Based Framework for this type of systems. The specific objectives in this area can be summarized as follows: Design of a quality-oriented P2P service architecture that supports self-configurable services and scalability from tiny embedded devices with wireless connections to heterogeneous P2P networked systems. Design of EP2P communication services with special focus on self-organisation, mobility, service discovery and delivery, and security. Design and implementation of a Component Based Framework to support the abstract service model previously discussed. Development of tools for quality analysis that facilitate the selection and instantiation of a concrete architecture depending on the types of devices and domain, and on the specific quality of service requirements for the application, such as reliability, performance and adaptability, Design and implementation of a set of components implementing the most important aspects of EP2P systems including, at least, security, reconfiguration and mobility. 2.3 Security EP2P security is one of the key aspects in the success of this type of systems, and it will be a central topic in the design of the SMEPP middleware. Traditional security infrastructures cannot be easily adapted to this type of systems, since most of them are based on trustable servers that provide authentication and authorization. On typical EP2P scenarios, this type of services will not be available and peers must provide their own authentication. In addition, the number of nodes in a system can range from dozens to thousands. Therefore, there is need for a scalable key infrastructure that allows information to securely flow over the entire network while maintaining a low number of keys per node. This infrastructure should also allow automatic distribution and maintenance of network keys using as little time and resources as possible. The main project goal in this area will be the design and implementation of such an infrastructure, and its integration in the SMEPP middleware. In certain scenarios, such as vehicle tracking[10] or videoconferencing, some nodes group themselves in order to cooperate to fulfill a certain task. There is the need for a key infrastructure for these dynamic groups. The key infrastructure will have to cope with the large number of nodes that can enter or exit the group in a short period of time. On the other hand, secure routing protocols for sharing the data between all the nodes must be designed. Existent protocols do not take security into account in the early stages of the design, thus they are very vulnerable in real-life scenarios. SMEPP secure routing protocols must comply with essential requirements such as connectivity, coverage, fault tolerance and scalability during the lifetime of the network. Moreover, some of the secure routing protocols should be designed to manage mobile nodes inside the network. Another aspect to take into account is the design of cryptographic protocols and security primitives to be used by embedded devices that have serious limitations (e.g., computational power, available energy). The protocols (e.g., authentication, key-exchange) and primitives (e.g., symmetric key primitives) have to be designed and specified in such a way as to achieve the security requirements while being energy efficient. The limited computational power of the nodes must also be taken into account. All these protocols and primitives will have to be properly validated using energy estimation methodologies and formal validations in the very early design stages. This will allow the selection of proper protocols and primitives, taking into account important issues such as side-channel attacks. Summing up, the main objectives in this area are: Design and implementation of a security infrastructure for EP2P systems and its integration into the SMEPP middleware. Design and implementation of secure routing protocols. Design and implementation of cryptographic protocols and security primitives for EP2P systems. 2.4 Applications The goal of this task is to validate SMEPP proposals through the development of chosen applications that represent very different scenarios. In particular, two specific applications will be implemented.

4 2.4.1 Environmental Monitoring in Industrial Plants. The first application is focused on environmental monitoring of industrial plants. Monitoring the effects of industrial plants on the environment is a key issue in different application domains and especially in the field of nuclear energy. The use of EP2P systems opens up new possibilities that will allow monitoring in the case of small leaks during inspection or even in the case of accidents where the measuring infrastructure is out of service. The application will have to be based on the joint use of sensor networks and MANETs for radiation measurement Mobile Personal Context Aware Communication Services. The second application will be carried out in the area of mobile personal context aware communication services, and it has quite different characteristics, with respect to the first one, both from the point of view of targetted terminals and of possible application characteristics and execution environments (the number of elements in the system can be very high and their mobility very superior to the first application scenario). This second application will be inspired by SeguiTel, a social and health care service platform developed by Telefónica I+D. This platform allows the provision of several telecare services (e.g., videoconference for tele-consulting, vital parameters reading, monitoring and communication, telesurveillance) following a client/server architecture. Users are registered and can subscribe to different services depending on their profile, needs and available home infrastructure. In order to better evaluate the validity of the approach, both applications will have to be as domain independent as possible, trying to make it easier to reuse parts of developed component in other applications based on the SMEPP middleware. 3 Key Requirements for the SMEPP Middleware In this Section we briefly describe the basic requirements of the SMEPP middleware that have already been identified. The requirements are divided into functional and non-functional ones. 3.1 Functional Requirements Functional requirements describe the high-level functionalities of the middleware at the level of the API and associated middleware support tools. Peer identification and associated information In EP2P systems global IP addresses or security certificates will be usually neither available nor useful. When a node interacts with other nodes the system must supply it a unique identification. Group characterization Groups will be a basic abstraction on the middleware. A group is a set of peers that share services or provide services to other peers. They are the basic abstraction for identification, security, communication broadcasting and service providing. Group Creation / Management A peer must be able to create a group by itself, establishing the security requirements for the group. A peer can also search for existing groups and join them if it is authorized to do so. Group Security Security is bound to groups. A group must be able to accept or reject a new peer based on the security services and the credentials of the peer. The security policy in the group is established by the group creator. Broadcast information to a group The middleware must support secure and ordered multicast of messages and events at the group level. Search in a group The middleware must provide mechanisms to locate services and other peers inside a group. Graphing services The middleware must have all the necessary mechanisms to control the network interconnection topology of a group of peers. The graph maintaining services must maintain efficient communications between peers and it must be simple enough to be deployed in resource limited nodes connected by low bandwidth communication mechanisms. Service Support The SMEPP middleware will be based on services. A service is always offered inside a group by one or more peers. Service discovery will be carried out at the group level. A peer must belong to a group to use the services offered by the group. Service description will have to be provided by means of a specially designed language for SMEPP service description (service contracts) that will include information to allow its discovery, adaptation, use or composition with other services. Localization The SMEPP middleware must provide localization services at the logical and physical levels. It must be

5 possible to find a peer in the groups where it offers services from its peer identification. Physical localization will be provided only if the deployment environment allows it and the applications need this information. P2P Communications Once a service is discovered and a peer is ready to offer the selected service, a direct communication among peers is established. This communication can be synchronous (results are returned just after the service invocation), asynchronous (results are returned at any moment after service invocation), or event-based (peers subscribe to a service, events are received by all the subscribers). Mobility Management The topology of the networks can change dynamically and some nodes can go out of the wireless network range. The middleware must be able to use other alternative networks to reach peers. 3.2 Non-Functional Requirements Security inside the middleware Security must be considered at all the levels of the middleware. Management of credentials must be as abstract as possible. A main issue on security is that an authority for authentication may not be reachable, so new authentication mechanisms must be supported. Interoperability with internet standards/legacy systems SMEPP middleware must support the integration of legacy software and the interconnection with other existing middleware such as CORBA should be possible, e.g., by middleware reconfiguration. Adaptation and configuration to different devices/os platforms The SMEPP middleware system architecture must be implementable on a variety of heterogeneous platforms, in terms of networking interfaces (802.11, Bluetooth, Infrared, cellular, Ethernet, etc.), of Operating Systems (TinyOS, Linux, Contiki, Windows CE, etc.), of networking protocols and underlying hardware platforms. The middleware system must provide bindings for development using different programming languages, such as Java[11], nesc[12]. Real-Time Requirements The middleware must support virtual communication channels between individual nodes. In some applications, the channels must be able to provide latency guarantees. Other QoS Requirements The middleware system should be able to monitor the quality of resources (reliability, fault-tolerance, etc) and adapt, depending on application constraints. Energy Awareness For certain types of devices (e.g., sensors) energy needs to be consumed in an economic and managed quantity. The middleware should provide schemes to aid a programmer to define energy requirements and schedules in a natural way. Scalability Scalability must be taken into account in terms of number of peers, geographical coverage, traffic load and so forth, and the interaction model must support small applications, like the ones in home domain as well as very large systems with hundreds of sensors and/or mobile devices. Requirements on the hardware SMEPP will have to be designed to run in small devices like sensor networks. All the peers must have at least a MAC address to ease the development of the identification related issues. Peers must be also able to connect, at least using one of the currently available wireless technologies. 4 Concluding Remarks To date, work on middleware for P2P systems has mainly been focused on content sharing applications. In these applications, quality of service and connection management criteria are completely different from those appearing in the systems we are dealing with[13]. Generic P2P platforms such as JXTA[6] or Microsoft Windows P2P Framework[8] are mainly concerned with networking aspects such as peer discovery, name resolution, graphing and routing. These platforms are computationally expensive and hence difficult to adapt to typical resource constrained embedded devices. Moreover, these applications are difficult to design and implement because of the absence of appropriate architectural abstractions to upper applicative layers, of the complexity of the underlying protocols, and of the ever-increasing complexity of the requirements. Code reuse and application customization are especially difficult, making the development of distributed applications in a heterogeneous environment even more difficult. There is also some preliminary work related to the development of middleware for EP2P[2], mainly focused on supporting the reconfiguration of ad-hoc networks and the aspects concerning resource management, such as memory and battery consumption. Some representative examples in the field of sensor networks and MANETS

6 are analysed in[15][13][14]. AMIGO project[4] aims to develop open, standardized, interoperable middleware for ambient intelligence. All these middleware platforms represent great progress, easing some aspects of the development of EP2P, but they do not solve a number of important problems, such as: They do not deal with the peculiar security aspects of EP2P. They do not provide an abstract model that allows the developers to focus on the application logic. They do not feature up-to-date support to provide a global quality of service of the system. They do not control the reconfiguration of the network in order to satisfy the quality of service, or to manage the consumption in a global manner (e.g., sometimes some nodes of the network are more critical than others and it is necessary to minimize the consumption of one node at the expense of increasing the consumption of another). The SMEPP project aims at addressing all those aspects in order to create a middleware that is able to satisfy the requirements of the project. The project will validate the middleware by the implementation of two different applications, one in the field of Environmental Monitoring in Industrial Plants, the other one in the field of Mobile Personal Context Aware Communication Services. 10. J. Anda, J. LeBrun, D. Ghosal, C. N. Chuah and M. Zhang, VGrid: Vehicular AdHoc Networking and Computing Grid for Intelligent Traffic Control, IEEE 61st Vehicular Technology Conference VTC 2005 Spring, 29th May - 1st June, Stockholm, Sweden 11. The Java homepage: The nesc homepage: G. Kortuem. Proem: A Middleware Platform for Mobile Peer-to-Peer Computing, ACM Mobile Computing and Communictions Review, Vol. 6, N V. Kalogeraki, F. Chen, Managing Distributed Objects in Peer-to-Peer Systems, IEEE Network, enero/febrero 2004., pp W. B. Heilzman, A. Murphy, H. S. Carvalho, and M. A. Perilo, Middleware to Support Sensor Network Applications., IEEE Network. Enero/Febrero pp References 1. S. Ratnasamy and P. Francis and M. Handley and R. Karp and S. Schenker, A scalable content-addressable network, SIGCOMM 01: Proceedings of the 2001 conference on Applications, technologies, architectures, and protocols for computer communications, pag P. Costa, G. Coulson, C. Mascolo, G. Pietro, S. and Zachariadis, The RUNES Middleware: A Reconfigurable Component-based Approach to Networked Embedded Systems 3. S. M. Brennan, A. M. Mielke, and D. C. Torney, Radiation Detection with Distributed Sensor Networks., IEEEComputer. August M. Vallée, F. Ramparany, L. Vercouter: A multi-agent system for dynamic service composition in ambient intelligence environments., Advances in Pervasive Computing, Adjunct Proceedings of the Third International Conference on Pervasive Computing (Pervasive 2005), May 8-11, 2005, Munich, Germany. (2005) 5. D. S. Wallach, A Survey of Peer-to-Peer Security Issues. Lecture Notes in Computer Science, Vol. 2609, p 42-57, January The JXTA home page 7. P. Baronti, P. Pillai, V. Chook, S. Chessa, A. Gotta, and Y. F. Hu, Wireless Sensor Networks: a Survey on the State of the Art and the and ZigBee Standards, Computer Communications, 30, 2007, pp PeerToPeer/default.aspx 9. M. Matinlassi, E. Niemela, L. Dobrica, Quality-driven architecture design and quality analysis method. A revolutionary initiation approach to a product line architecture. Espoo, VTT Electronics, 2002, VTT Publications 456, 128 p p. ISBN ;