Secure Service Discovery Middleware

Discovery mechanisms are usually used to explore the environment and to adapt to the different interfaces provided to connect to relevant services. The definition of specific middleware is necessary in order to provide standardized interfaces facilitating the interconnection of mobile devices and services. Various solutions like J2EE, .Net, or CORBA have been developed providing a middleware abstraction over which one can deploy standardized discovery protocols such as WS-Discovery, UPnP, Jini, or SLP. However, these middleware have never specifically addressed security problems in the spontaneous networking framework, which usually rely on too static assumptions that hamper the dynamic deployment of services. In particular, an administrator has to know in advance users and services of the system in order to ensure their protection. In this section we aim to provide a flexible and adaptive middleware abstraction layer inspired from the architecture described in the section Chapter III.D that programmers might easily integrate via a plain Java API or through a Web Service interface.

1. Related Work

Several studies were published in the literature that proposes different middleware platforms to enable an efficient service discovery. This section provides an overview of various such platforms. To our knowledge however, no actual implementation of a security oriented service discovery middleware platform answering spontaneous networking challenges was ever described before.

[BIS06] introduces a service discovery middleware framework for an ad-hoc network of devices. This architecture relies on a hierarchy of distributed registries called “Service Repository”. In order to verify if all the published services are still “alive”, every registry polls the rest of the network and requests the other registries to report their local services. The authors compared the M2MI framework to Jini’s service discovery that is quite similar in its functionalities.

[SOM07] aims at answering the challenges of the service discovery in partially connected or disconnected mobile ad-hoc networks. It first lists the issues that must be addressed in order to overcome the problems related to mobility and to the lack of permanent connectivity (flexible addressing scheme, supporting asynchronous communications, content based management of messages, and taking into account special and temporal contextual properties of the services. The core framework of this proposal is based on the OSGi framework which the authors extended in order to describe local and remote services and to enable a proactive and reactive service discovery. Contextual properties are added to characterize mobile hosts.

With the emergence of pervasive computing environments, [CAM05] proposes a pervasive discovery policy associated with a service description language (GSDL). In terms of new challenges raised by discovery in such a programming paradigm, this paper only focuses on network transmissions minimization, on the decentralization of the discovery infrastructure, and on cooperation between different systems. The challenges described concerning service description are the need for simplicity to adapt to the limited power and computing capacity of the devices, the need for scalability, and the need to retain compatibility with all kinds of platforms. The discovery algorithms presented prioritize between existing services by warding the more static devices with more opportunities of answering requests. The GSDL description language, which can be considered as an extension of the WSDL language, provides a hierarchical description of the services for specifying the relationship between different services. This hierarchical categorization provides more scalability for service publication. The security middleware solution from which we inspired most has been published in[JIA05]

and addresses ubiquitous computing environments. The middleware provides a way for the users and the administrators to define security policies for context-aware trust management. Such a security policy was implemented by the authors. They define three kinds of policies: an authorization policy (access control policy), a delegation policy (that allows user to delegate his rights to another user), and an obligation policy that triggers actions in response to specific events in the system. The middleware consists of five components: a policy manager, used for the policy reasoning and enforcement; an object manager that provides a monitor control of the different objects involved in the system; a context manager, which collects and analyzes the contextual information from the sensors; finally an authentication manager, used to verify and manage the X.509 certificates provided by the users and the artifacts.

2. Middleware Stack

The heart of the platform is a middleware including a set of security services, notably for automatic SOAP traffic encryption and signature. Finally, applications are either written on top of the middleware or, in case of legacy applications, are adapted to use this middleware. Application-specific policies can be defined to configure the platform. The secure discovery middleware is intended to provide a secure and adaptable service discovery interface. This system could be used by service providers in order to securely publish their services by imposing their own security requirements. Users also have a way to discover and locate services without exposing their identities or attributes to unbeknownst and potentially untrusted entities, and of requesting that the services they are discovering adhere to specific security requirements.

The discovery service is accessible to client applications through a Web Services interface. This API gives access to records in a service registry that can be implemented in a centralized or distributed fashion. The current implementation supports the peer-to-peer WS-Discovery protocol that is nicely suited to spontaneous networking, even though some provision has been made in the middleware to integrate other types of directories, most notably UDDI based ones. This API is also accessible through Java methods. Using this interface, a server can:

declare its services by publishing their profile;

upload a security discovery policy for each of these services to the registry;

upload certified credentials to the registry that will make it possible for the latter to authenticate the former.

Clients also use this interface in order to request for a specific service, described according to an extensible set of attributes. They can also upload a security discovery policy and certified credentials for authentication.

As can be readily seen from the above description, the registry is the decision (PDP) and enforcement point (PEP) for the discovery policy, two functions which both rely on the use of certified credentials. As a decision point however, the registry also relies on context evaluation, as described below.

Figure 34 : Middleware Stack

The middleware stack shown in Figure 34 is composed of three layers:

Discovery Protocol Layer: This layer specifies the message formats, the message

sequencing, and the processing rules. Discovery follows the WS-Discovery protocol, which was slightly extended to accommodate an explicitly designated registry based on WS-Discovery proxies. Packets are routed via Multicast in case of a public announcement (messages from the service to groups of registries) or Unicast in case of a direct request (messages from the client to a registry). UDP datagrams are sufficient to guarantee a coherent discovery connection without setting up a TCP connection. A UDP message must be sent at least 3 times to guarantee its reception from the concerned party. Other discovery protocols dedicated to service discovery like UPnP, Jini, or SLP might be integrated if legacy systems are to be used.

Security Layer: This part of the stack provides tools and methods used to:

authenticate clients and services (identity and wrights verification), decide and enforce the security policy provided by clients and services, and finally perform an access control to restricted resources.

API Layer: It represents the visible interface accessible to the user. It provides the

information helpful for the users in order to access to the service discovery Middleware. Two interfaces, a Java library, and a WSDL description are provided (see the Annex ).

G. Security Evaluation

In this chapter we proposed a secure service discovery protocol relying on a centralized trusted registry in charge of enforcing security discovery policies. In this section we present the secure properties of this protocol.

Proof- Restricted services provide to the registry, during the registration, a security policy

limiting the discovery of the services to clients that profile corresponds to the conditions expressed in the policy. If a client’s request matches with a restricted service, the registry will authenticate the client, extract the attributes of the client and match it with the attributes specified in the service’s policy. If the policy is not satisfied the registry will not respond to the client in order to specify that the service does not exist.

Property 2 it could impossible for a fake service to be discovered by clients

Proof- Client could attach to their service request a security policy to verify the authenticity of

the selected services. If this request matches with a service the registry first authenticate the selected service and verifies if it is compliant with the conditions expressed by the client’s policy. For example the matched service is a printer service the registry has to verify if the

printer is one of the attributes of service’s certificate, else no response will be sent to the

client.

Property 3 communication between client / service and registries are secure

Proof- since SSL/TLS is systematically used between clients, service and registries, discovery

messages are exchanged through a secure channel. The number of exchanged messages is not enough important to permit an attacker to break the encryption system.