UPnP is a specification for connecting multiple devices on a home network so that these devices can invoke services of each other. UPnP defines a set of protocols and a service description format. In addition, UPnP standardizes various service interfaces. UPnP relies on administratively scoped multicast IP address for service discovery, service advertisement, and event delivery. Each UPnP device broadcasts its advertisements when it first connects to the network. Thereafter, a UPnP device broadcasts advertisements in response to queries from other devices. These queries may be for all services on the network or a specific service on
the network. UPnP Device Security specification defines security mechanisms for simple object ac- cess protocol (SOAP)-based service invocation, but does not address simple service discovery protocol (SSDP) security.
As an extension of project Centaurus (Kagal, Korolev, Avancha, et al., 2001; Kagal, Korolev, Chen, et al., 2001), Centaurus2 (Undercoffer et al., 2003) provides a secure mechanism for service dis- covery and enables users to access services across
heterogeneous network domains. The system uses a local certificate authority (CA) and each entity must be pre-registered in the system. The CA issues a certificate to each identified and verified entity. The design of Centaurus2 includes four components, and each component has a separate private key which is stored at the client using PKCS #11: 1. The local CA is responsible for issuing digital
certificates and for validating these digital certificates. Model Adaptive Infrastructure support needed lightweight service- oriented trust Aware Privacy Aware context Aware smart space needed
SSDS No Yes No No N/A N/A N/A No
Ninja No Yes No No N/A N/A N/A No
UPnP No N/A No No No Yes No Limited
SPDP No No Yes No Yes N/A No No
Progressive
Exposure No Yes No No No Yes Limited No
Splendor No Yes No No Yes Yes N/A No
Jini No N/A No No N/A Yes N/A Limited
CSAS No No Yes No N/A N/A Yes No
CSM Yes No Yes No N/A N/A Yes No
AVCM Limited No Yes No Yes Yes Yes No
CSRA No Yes No No N/A N/A Yes Yes
TRAC No N/A No No Yes Yes N/A Yes
SME Yes N/A N/A Yes N/A Yes No N/A
HCA No N/A Yes No No Yes No N/A
SSRD Yes No Yes Yes Yes Yes Limited No
SSRD+ Yes No Yes Yes Yes Limited Yes No
Centaurus Yes Yes No No No N/A Yes No
SLP No Yes Yes Yes No No No No
Sleeper Yes No Yes Yes Yes Yes No No
Table 1. Comparison of secure service discovery models (SSDS): SSDS (Czerwinski et al., 1999), Ninja (Goldberg, Gribble, Wagner, & Brewer, 1999; Gribble et al., 2001), UPnP (Miller et al., 2001), SPDP (Almenarez & Campo, 2003), Progressive Exposure (Zhu et al., 2004; Zhu, Mutka, & Ni, 2006), Splendor
(Kagal, Korolev, Chen, Joshi, & Finin, 2001), Jini (Sun Microsystems, 2001), CSAS (Minami & Kotz,
2005), CSM (Brezillon & Mostefaoui, 2004), AVCM (Shankar & Arbaugh, 2002), CSRA (Tripathi, Ahmed, Kulkarni, Kumar, & Kashiramka, 2004), TRAC (Basu & Callaghan, 2005), SME (Kopp, Lucke, & Ta-
vangarian, 2005), HCA (Pearson, 2005), SSRD (Sharmin, Ahmed, & Ahamed, 2006a), SSRD+ (Sharmin, Ahmed, & Ahamed, 2006b), Centaurus2 (Undercoffer, Perich, Cedilnik, Kagal, & Joshi, 2003), SLP (Barbeau, 1999; Guttman, Perkins, Veizades, & Day, 1999), Sleeper (Buford, Celebi, et al., 2006)
2. The communication manager mediates com-
munication between clients and networked services.
3. Group membership(s) is maintained and stored by the capability manager.
4. Each client is registered to a specific service manager that ensures security, access rights, and mediates between user client and service client. Service managers maintain a service registry.
Each domain has a root service manager. Static bridges are configured between service managers in different domains. Then clients in separate do- mains can access services across domains using the root service manager as the context.
In SSDS (Czerwinski et al., 1999), both service advertisement pull (query) and push (announce- ment) are supported. Service advertisements are stored in a hierarchy of servers. SSDS provides capability-based access control. All information passed between clients and servers is encrypted. A single copy of the resource information is stored and accessed, which makes the system vulner- able to single point failure. Subsequently, the Ninja project (Goldberg et al., 1999; Gribble et al., 2001) added the concept of secure identification of service through SSDS. In Ninja, the CA issues valid certificates and the capability manager au- thorizes user access to a particular resource. The service providers can also prescribe the conditions (capabilities) that are needed by a user in order to discover a particular service.
The context-sensitive authorization scheme (CSAS) (Minami & Kotz, 2005) provides authoriza- tion without a central server or CA. When a CSAS user wants to access a service from a resource, the associated server issues a logical authentica- tion query and sends it to the host of the resource. Each host has a knowledge domain with which it attempts to prove the authorization query. If it fails, it distributes several portions of the proof to multiple hosts. Through this distribution CSAS reduces the computational overhead on any single node. After collecting the sub-proofs from the other hosts, the host of the resource can declare the result of the query to be true or false, thus indicating grant of
access or denial respectively. This approach fa- cilitates confidentiality, integrity, and scalability. To authorize access, CSAS uses previously stored information, which may be difficult to collect for users in an ad hoc network.
Splendor (Zhu et al., 2003) is a secure, private, and location-aware service discovery protocol. Splendor adapts depending on the network en- vironment to use either a client-service model or client-service-directory model. Proxies are used to offload workload for mobile services. Mobile ser- vices authenticate with proxies and proxies handle registration. In these situations, proxies are consid- ered to be trusted servers. However, if no trusted server is available in an environment, then there is no agent to handle the registration. Its security model is based on mutual authentication.
Progressive Exposure (Zhu et al., 2004, 2006) is a secure service discovery approach. It ad- dresses privacy issues using a mutual matching technique. Progressive exposure addresses security and fairness by not exposing too much informa- tion. In each round of message exchange between communicating parties, it tries to find whether any mismatch occurs. In case of a mismatch, the communication stops. It uses one-time code words and a hash-based message authentication code. It considers the presence of one user and one service provider, but it does not address situations in which many users and many service providers are present. When a service provider leaves the network, the process of provider lookup and the authentication phase is restarted. It provides privacy for service information, requests, domain identity, and user credentials, and is based on the client-service- directory model.