Michele Albano Antonio Brogi Razvan Popescu Manuel D az Jos e A.

Dianes

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

Received: June 1st, 2007 / Accepted: July 2nd, 2007

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 Keywords Embedded Peer-to-Peer Systems Secure of the house (e.g., switch o the air conditioning if Middleware nobody is in the room). Mobile telephony. The features of new programmable mobile phones make them real execution platforms, 1 Introduction supporting multitasking and real-time operating systems and ubiquitous connectivity. With specic probP2P systems are distributed computing systems where lems such as high latency, reduced bandwidth, and all network elements act both as service consumers (clients) dependency on batteries, mobile phones are an interand service providers (servers). Moreover, most of the esting eld for developing new applications such as mechanisms of communication are not based on prenetwork games or mobile sensor applications[7]. existing infrastructures, but rather on dynamic ad-hoc networks among peers[1]. The potential advantages of EP2P are adaptability, Embedded Peer-to-Peer Systems (EP2P)[2] represent scalability, high availability, and ubiquity, as the model a new challenge in the development of software for dis- is based on the possibility of incorporating and removtributed systems. An EP2P is a P2P system where small, ing resources in a dynamic and adaptive way, and users low-powered, low-cost embedded systems collaborate in should be able to access those resources oered by the the processing and management of information using network anytime, anywhere. wireless channels. The main drawbacks are also due to these characEP2P systems are exible enough to be applied in teristics. EP2Ps present a high degree of heterogeneity diverse areas, such as: (applications may run on dierent devices, from PDAs to Environmental monitoring. Monitoring of the eects sensor network nodes, with quite dierent network bandof industrial plants on the environment is a key issue widths and computing power) and autonomy (the elein dierent application domains and particularly in ments enter the system and exit in an independent way, the eld of nuclear energy[3]. The use of EP2P opens causing frequent reorganizations of the systems). These up new perspectives that allow monitoring in the case drawbacks raise important technological challenges such as decentralization, links with transient communications This work has been partially supported by the SMEPP (connections and disconnections happen in an unpreproject (EU-FP6-IST 0333563). dictable and frequent manner), and a constantly changing topology. M. Albano, A. Brogi, R. Popescu Department of Computer Science, University of Pisa, Italy In addition, there is a major problem that any EP2P system must deal with: Security. Traditional P2P sysM. D az, J. A. Dianes Dpt. of Languages and Computer Science, University of tems have to face attacks on the routing protocols, atM alaga, Spain tacks against the identity of the nodes, and threats against 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 dierent types of requirements that have been identied in SMEPP.

the condentiality, 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 denition, creation and maintenance of applications. The paper is organized as follows. Section 2 presents the general requirements that have been identied for SMEPP. Section 3 discusses detailed requirements for the architecture of SMEPP middleware. Conclusions and nal remarks are presented in Section 4.

customizable, allowing for its adaptation to dierent 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 eorts and specic project objectives have been organized into four main classes that are briey discussed in the following sub-sections.

2.1 Service and Interaction Model The high degree of self-conguration and self-management required in EP2P has a signicant 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 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 nal architects and developers. Without middleware (including formal tools and methodologies), the denition, 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, identication 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 specic middleware for EP2P. The middleware will have to be secure, generic and highly

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 specic services and proles (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 dening 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 eld. The main objective of the SMEPP project in this area is the

denition of a new middleware architecture specic 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 dierent 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 recongurable middleware systems, they do not deal specically with EP2P systems and SMEPP will develop a specic Component Based Framework for this type of systems. The specic objectives in this area can be summarized as follows: Design of a quality-oriented P2P service architecture that supports self-congurable 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 specic 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, reconguration and mobility.

to securely ow 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 fulll 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 specied in such a way as to achieve the security requirements while being energy ecient. 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.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

2.4 Applications The goal of this task is to validate SMEPP proposals through the development of chosen applications that represent very dierent scenarios. In particular, two specic applications will be implemented.

2.4.1 Environmental Monitoring in Industrial Plants. The rst application is focused on environmental monitoring of industrial plants. Monitoring the eects of industrial plants on the environment is a key issue in different application domains and especially in the eld 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. 2.4.2 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 dierent characteristics, with respect to the rst 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 rst application scenario). This second application will be inspired by SeguiTel, a social and health care service platform developed by Telef onica 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 dierent services depending on their prole, 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.

In EP2P systems global IP addresses or security certicates will be usually neither available nor useful. When a node interacts with other nodes the system must supply it a unique identication. 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 identication, 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 ecient 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 oered 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 oered 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

3 Key Requirements for the SMEPP Middleware In this Section we briey describe the basic requirements of the SMEPP middleware that have already been identied. 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 identication and associated information

possible to nd a peer in the groups where it oers services from its peer identication. Physical localization will be provided only if the deployment environment allows it and the applications need this information.

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 P2P Communications For certain types of devices (e.g., sensors) energy Once a service is discovered and a peer is ready to ofneeds to be consumed in an economic and managed fer the selected service, a direct communication among quantity. The middleware should provide schemes to peers is established. This communication can be synaid a programmer to dene energy requirements and chronous (results are returned just after the service schedules in a natural way. invocation), asynchronous (results are returned at any moment after service invocation), or event-based (peers Scalability subscribe to a service, events are received by all the Scalability must be taken into account in terms of subscribers). number of peers, geographical coverage, trac load and so forth, and the interaction model must support Mobility Management small applications, like the ones in home domain as The topology of the networks can change dynamically well as very large systems with hundreds of sensors and some nodes can go out of the wireless network and/or mobile devices. range. The middleware must be able to use other alternative networks to reach peers. 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 3.2 Non-Functional Requirements the identication related issues. Peers must be also able to connect, at least using one of the currently Security inside the middleware available wireless technologies. 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 sup- 4 Concluding Remarks ported. To date, work on middleware for P2P systems has mainly Interoperability with internet standards/legacy systems been focused on content sharing applications. In these SMEPP middleware must support the integration of applications, quality of service and connection managelegacy software and the interconnection with other ment criteria are completely dierent from those appearexisting middleware such as CORBA should be pos- ing in the systems we are dealing with[13]. Generic P2P platforms such as JXTA[6] or Microsoft Windows P2P sible, e.g., by middleware reconguration. Framework[8] are mainly concerned with networking as Adaptation and conguration to dierent devices/OS pects such as peer discovery, name resolution, graphing and routing. These platforms are computationally explatforms The SMEPP middleware system architecture must pensive and hence dicult to adapt to typical resource be implementable on a variety of heterogeneous plat- constrained embedded devices. Moreover, these applicaforms, in terms of networking interfaces (802.11, Blue- tions are dicult to design and implement because of tooth, Infrared, cellular, Ethernet, etc.), of Operat- the absence of appropriate architectural abstractions to ing Systems (TinyOS, Linux, Contiki, Windows CE, upper applicative layers, of the complexity of the underetc.), of networking protocols and underlying hard- lying protocols, and of the ever-increasing complexity of ware platforms. The middleware system must pro- the requirements. Code reuse and application customizavide bindings for development using dierent pro- tion are especially dicult, making the development of distributed applications in a heterogeneous environment gramming languages, such as Java[11], nesC[12]. even more dicult. Real-Time Requirements There is also some preliminary work related to the deThe middleware must support virtual communication velopment of middleware for EP2P[2], mainly focused on channels between individual nodes. In some applica- supporting the reconguration of ad-hoc networks and tions, the channels must be able to provide latency the aspects concerning resource management, such as guarantees. memory and battery consumption. Some representative examples in the eld of sensor networks and MANETS

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 reconguration 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 dierent applications, one in the eld of Environmental Monitoring in Industrial Plants, the other one in the eld of Mobile Personal Context Aware Communication Services. 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.161172 2. P. Costa, G. Coulson, C. Mascolo, G. Pietro, S. and Zachariadis, The RUNES Middleware: A Recongurable 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 2004. 4. M. Vall ee, 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 2003. 6. The JXTA home page http://www.jxta.org 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 802.15.4 and ZigBee Standards, Computer Communications, 30, 2007, pp. 1655-1695. 8. http://msdn.microsoft.com/msdnmag/issues/06/10/ 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. + 10 p. ISBN 951-38-5967-3; 951-38-5968-1.

10. J. Anda, J. LeBrun, D. Ghosal, C. N. Chuah and M. Zhang, VGrid: Vehicular AdHoc Networking and Computing Grid for Intelligent Trac Control, IEEE 61st Vehicular Technology Conference VTC 2005 Spring, 29th May - 1st June, Stockholm, Sweden 11. The Java homepage: http://java.sun.com 12. The nesC homepage: http://nescc.sourceforge.net 13. G. Kortuem. Proem: A Middleware Platform for Mobile Peer-to-Peer Computing, ACM Mobile Computing and Communictions Review, Vol. 6, N. 4. 2004 14. V. Kalogeraki, F. Chen, Managing Distributed Objects in Peer-to-Peer Systems, IEEE Network, enero/febrero 2004., pp. 22-29. 15. W. B. Heilzman, A. Murphy, H. S. Carvalho, and M. A. Perilo, Middleware to Support Sensor Network Applications., IEEE Network. Enero/Febrero 2004. pp 6-14.