Architecture Framework for Device Single Sign On in ... - Springer Link

6 downloads 4071 Views 3MB Size Report
Over the years, a lot of research and development has been going on in this field. One of ... Section 5 describes our custom application and section 6 concludes ...
Architecture Framework for Device Single Sign On in Personal Area Networks Appadodharana Chandershekarapuram, Dimitrios Vogiatzis, Spyridon Vassilaras, and Gregory S. Yovanof Athens Information Technology {acha, dvog, svas, gyov}@ait.edu.gr

Abstract. This paper addresses the Single Sign On (SSO) issue in personal Area Networks (PANs) comprising of heterogeneous handheld devices. Architectures for service SSO solutions at the enterprise level are already in the market and some standards for such solutions exist. In this paper however we introduce the notion of device level SSO. By device SSO, we refer to the process of logging on to one device and then subsequently being authorized for other devices on a need only basis, without the user being prompted for his credentials or requiring any further manual interaction. Device SSO secures the authentication process in a PAN and alleviates the users from the burden of handling and managing the credentials of each device in the PAN. While borrowing elements from the enterprise level SSO standards, our architecture has been custom-tailored to the characteristics and inherent features of a PAN environment. Client server and peer-to-peer SSO schemes have been designed to fit both PAN star and mesh architectures. The proposed scheme is an application layer solution that is independent of the device platform and the underlying radio link. A sample prototype application has been developed as a proof of concept that runs on laptops and PDAs communicating over Bluetooth links.

1 Introduction A Mobile Ad-hoc Network (MANET) consists of set of mobile nodes which form peer to peer connections in an automatic and distributed way when they come in close proximity to each other. MANETs do not demand an infrastructure or centralized controller for maintaining the network. In such a case the mobile nodes themselves can act as forwarding devices to establish communication between other nodes in the network. Over the years, a lot of research and development has been going on in this field. One of the major issues in the case of MANETs is the secure authentication of nodes entering the network. This is the first and necessary step that guarantees the identity of the user and provides for secure communications between the nodes. A Personal Area Network (PAN) can be considered as a special type of MANET, formed by a set of mobile devices in close proximity that typically belong to a single person. Due to this reason, PANs are usually of limited size. The network itself is heterogeneous in nature, in the sense that it is composed of different devices, ranging from cell phones and PDAs to laptop and desktop PCs. Due to its nature, a PAN can R. Meersman, Z. Tari, P. Herrero et al. (Eds.): OTM Workshops 2006, LNCS 4278, pp. 1367 – 1379, 2006. © Springer-Verlag Berlin Heidelberg 2006

1368

A. Chandershekarapuram et al.

be used as a tool for synchronization of personal information among various devices, as well as data sharing and lightweight personal service provisioning. As in the case of MANETs, the wire free aspect of a PAN poses difficulties in the authentication of the nodes. However, the fact that most of the time a PAN belongs to the same entity/user introduces an additional level of difficulty with respect to the network’s security, set-up and maintenance. The owner of the PAN is required to maintain a different sets of credentials for each device in the PAN in order to decrease the possibility that an unauthorized user accesses multiple devices, once he compromises a single password. However, it is obvious that this leads to increased complexity and overhead in terms of network maintenance, since it involves the storage or memorizing of multiple passwords. It would be more efficient for the user to maintain a different set of credentials for each of the devices and then use one device to be responsible for the identification and authentication of the other devices that are in its close proximity. This scheme is known as Single Sign On (SSO). A PAN SSO scheme has to take into account the network architecture of the PAN. PAN architectures usually follow either the client-server/star model or the peer-topeer/mesh model. In the first case the authentication and communication between the nodes has to go through a primary device, called ‘server’. In the latter case, every device can authenticate any other device that is signing in the network. We propose SSO solutions for both types of architectures. For the client-server model, the SSO scheme is based on a variation of the Kerberos authentication protocol, whereas for the peer-to-peer model, we base our solution on a variation of the Bluetooth authentication protocol. Apart from that, as it was mentioned earlier, a PAN consists of a set of devices which are heterogeneous both in hardware and software. Small personal handheld devices, having limited computing power, little or no memory at all and limited battery life, impose several power constraints and memory limitations to a PAN network, which are taken into account and dealt with properly within the proposed SSO scheme. The rest of the paper is organized as follows: In Section 2 a brief overview of the problem is provided, along with the description of related work on the subject. Section 3 summarizes the operation of the Kerberos authentication protocol. In section 4 we present the proposed SSO scheme for a PAN, both for the client server and the peer-to-peer model. Section 5 describes our custom application and section 6 concludes the paper.

2 Single Sign On in PANs Currently, the Single Sign On problem has been extensively studied and analyzed in the context of multiple users signing in different services across the Internet [1]. A user/employee in a big Enterprise or a user of the Internet while roaming between a great variety of offered services, always faces the problem of maintaining multiple identities and passwords for those identities. This is often problematic for both the service provider (SP) and the client availing the service, in the sense that the client is often inclined to use the same set of credentials over different services. Consequently such an event increases the threat of theft of sensitive information once the profile for one of the services is compromised. In case the user chooses to maintain a different

Architecture Framework for Device Single Sign On in Personal Area Networks

1369

password and identity for each service, the process of doing so is very cumbersome and should be done meticulously. Also, in the latter approach there is a higher chance that a user could forget his password and at times even his username. The SP therefore has to have a mechanism to provide a solution for this impasse. The usual solution is to provide a ‘password reset’ mechanism based on some predefined secret (e.g. answer to a predefined question) that the user and the SP have agreed upon at the time of user registration. With the advance of short range wireless communications, the emergence of short range protocols, such as Bluetooth, ZigBee, UWB, etc. and the development of many new, innovative personal devices, Personal Area Networks are increasingly deployed for short range transactions and applications. In such networks it is evident that a different aspect of the Single Sign On problem emerges, which has to do with the “registration” and management of so many devices (most often owned by the same user) in a single network. In the common case, the owner of the PAN has to provide the login and password for each new device that requires to enter the network. However, such a solution increases the complexity and the overhead imposed, since the user has to memorize the passwords for each network device. At the other extreme, having a single password for all the devices, leads to increased probability of network compromise by the time the password is revealed once. Ideally, what we would like is that this login procedure is followed once at a single device and then all the other devices sign in the network in a transparent to the user way. The signing-in process could be initiated upon switching a device on and/or when it comes into the proximity of another device that has already signed in the PAN. The device that is chosen to lead this procedure, could be either the first device that logs in the network or the most powerful device in terms of power (or other resources) that is currently logged in the network. Alternatively, any other predefined and properly selected rule could be followed as well. Therefore, generalizing and slightly modifying the definition given in [2] with respect to service SSO, we could say that the device Single Sign On problem refers to the process of logging on to one device and then consequently being authorized for other devices on a need only basis, without the user being prompted for his credentials or requiring any further manual interaction. With respect to the service SSO, there are various SSO solutions available in the market that provide SSO services in different ways. Some of them are open standards while some are proprietary in nature. Some SSO solution schemes have been also implemented in hardware as well. The most known among them are the Kerberos protocol [14], the Liberty Alliance and SAML [4], the Microsoft .NET Passport [5], the SSO scheme using GSM/UMTS [6] and the SSO scheme proposed by the TCPA [7]. Although there certainly exist some common aspects between the service and device SSO instances, there are also some important differences that dictate the study and analysis of the PAN SSO on a separate basis. Some of these differences are presented below: 1. Existing service SSO solutions do not address the device SSO problem. They are basically designed to provide SSO across multiple services or applications as opposed to authenticating devices themselves. TCPA and the GSM/UMTS based SSO schemes could be used for device authentication as well, but still the primary

1370

2.

3.

4.

5.

6.

A. Chandershekarapuram et al.

objective is to provide web service authentication. In this work, we propose a SSO scheme to authenticate the device itself. Existing service SSO schemes aim at providing SSO for huge business organizations or web applications. This means that they demand the infrastructural resources that exist in such organizations. On the other hand a PAN SSO scheme should make use of primitives that just reside within the devices themselves. Service SSO schemes assume that a PKI is in place. Since the services are provided by a trusted entity that is well known, it is reasonable to have a Public Key Infrastructure for its security infrastructure, which facilitates identity management as opposed to symmetric key primitives. However this is not the case for a PAN, where the lack of PKI forces the devices to rely entirely on their own resources to carry out the duty of logging in. The service SSO solutions do not aim to provide mobility for the user or the verifier. In the case of a PAN SSO scheme though, the solution should also afford for a small amount of device mobility as well. The models for Enterprise SSO are mostly based on the Client Server model. This is not directly applicable though in a PAN environment, which is mostly ad hoc based and the peer-to-peer model is intuitively more suitable for PANs. Power management is not an issue for service SSO schemes. PANs though are made up of personal devices that impose severe power constraints due to their limited power budget. Thus, the design of a power aware device SSO scheme is of paramount importance for the case of PANs.

As we mentioned earlier, Liberty and SAML are working on the Single Sign On issue to make it available to the market for easy development of Single Sign On solutions. In addition, Shibboleth [8] is an internet2 initiative to provide federated identity management using the OpenSAML specifications. However, these are related to Single Sign On in a broader perspective, focusing mainly on web services or enterprise solutions. In [9] Jeong et al. propose a single sign-on scheme in which a mobile user offers his credential information to the home network to obtain user authentication and access to another domain based on the SAML standard. This approach resembles our approach in the way that it provides Single Sign On for a mobile environment with small devices. In [10] the authors discuss a distributed service for network authentication, allowing application servers to delegate client identity checking to combinations of authentication servers potentially residing in separate administrative domains. However, both [9] and [10] deal with the issue of providing SSO services for inter domain access and authentication and not for device sign on itself. The authors in [11] describe a scheme that enables two wireless devices to securely authenticate one another and agree on a shared data string. However this solution involves the manual interaction between the devices, which most of the time is not desirable and opposed to the single sign on concept and objectives.

3 Kerberos Since the solution that we propose for the PAN SSO problem is partially based on the Kerberos protocol, in this section we provide a brief description of the Kerberos authentication protocol.

Architecture Framework for Device Single Sign On in Personal Area Networks

1371

Kerberos is basically a Trusted Third Party Authentication Protocol. Kerberos is a distributed authentication service that allows a process (client) running on behalf of a principal (user) to prove its identity to a verifier (server) without sending data across the network that might allow an attacker or the verifier to subsequently impersonate the principal. RFC 1510 specifies the Kerberos 5 mechanism [14]. The basic working of Kerberos is outlined in Fig. 1. Kerberos authentication System consists of four entities: A server s, a client c, a Key Distribution Service (KDC) and a Ticket Granting Service (TGS). The KDC and the TGS entities act as the SSO component. The KDC is the authority that issues tickets to the client and the server. Specifically, the KDC issues a Ticket Granting Ticket (TGT) to the client. The client having the TGT, requests a ticket from the Ticket Granting Server (TGS). The TGS sends back a ticket to the client containing the secret key that the client and the server are going to use for the session. The client then passes this key to the server securely. Once they both have a copy of the secret key they can start communication.

Fig. 1. Kerberos Setup

The first time a user comes in, he logs into the SSO component to get a TGT from the KDC server. The client retains this ticket till its validity expires. For each new service from a new server that the client demands, the protocol automatically uses the TGT that it has already acquired from the KDC, and asks for a ticket for the new service. The fact that the client side does not have always to authenticate for each new service makes this system a service SSO scheme. In case the validity period of the TGT has expired, the client has to re-authenticate to the KDC and get a new TGT. However, in the context of device SSO provisioning within a PAN, the set up of the Kerberos system and the message exchange need to be tailored appropriately.

4 PAN SSO Architecture As mentioned previously this paper addresses the problem of a user having to maintain a multiple set of passwords and log on to his set of devices in the case of a PAN. Fig. 2 gives an overview of the scenario. The devices Dev1, Dev2 and Dev3 belong to a single person. Let’s assume that Dev1 is the one that is currently logged in by the user. This means that the device is turned on, authenticated and is authorized for a specific user to use it. The challenge is to automatically log in to all the other devices that this user owns using the already

1372

A. Chandershekarapuram et al.

logged in device. Let’s suppose that a second device Dev2 is within range of the device Dev1. To successfully log on to Dev2, it must be turned on and in the transmission range of Dev1. Assuming this is the case, Dev1 detects Dev2, and logs into Dev2 using the user name and password of the particular user for Dev2. The whole mechanism of logging in should be secure enough and therefore proper security handshakes must be used. The same should happen with a third device Dev3, in which case either Dev1 or Dev2 should be able to sign the new device in the PAN. After successful login each device would also maintain connection with the others so that they communicate securely on top of just being remotely logged in. This mechanism, though easy to visualize, is difficult to achieve. The SSO model for a PAN should take into account issues such as who should be the initiator of the sign-in process, who should be the decision maker in the network, etc. It should also provide a properly designed middleware to abstract the heterogeneity of the underlying radio technology, so that the proposed scheme could work equally well and efficiently either with Bluetooth or ZigBee or any other short range wireless technology. Since the devices range from high end desktops to mobile phones that are very limited in their computational power, the proposed SSO scheme uses security primitives that are portable even to the least capable device in the network. For this reason, symmetric key cryptography is selected. We further assume that the symmetric keys are distributed among the network and trust between the devices is established a priori. The Sign On in a PAN can happen between devices which are only one hop away. This means that a device can sign on to only its one-hop neighbors. In case of Sign On for multi hop neighbors we have to deal with authentication, trusting and routing issues. We are not concerned with such a scenario here. Since the SSO scheme is going to be deployed over a specific PAN architecture, it is essential that the designed SSO scheme adheres to the specific features of the architecture of the PAN network. For this purpose we propose two different PAN SSO schemes, namely the client server PAN SSO and the peer-to-peer (P2P) PAN SSO. The Client Server based model is usually designed for an environment where the user is logged into his Laptop or Desktop (typically at home or office). On the other hand, the Peer-to-Peer model is mostly valid for more dynamic environments where the user is on transit or highly mobile compared to a home environment. 4.1 The Client Server PAN SSO The Client Server model is a very common model for PAN architectures. An illustration of the client server model is shown in Fig. 3. In this case the server is the device in which the primary user login takes place and afterwards any other device in the network is authenticated and logged in by the server. Consider for example the case where a user uses his set of personal devices in his home or office. In this scenario, the device that is the most frequently used (in the sense that it is turned on and logged in most of the times) assumes the role of the server. Typically, such a device could be the desktop or the laptop of the owner of the PAN. Let’s assume now that a new device (C1 or C2 as in Fig. 3), which is in the

Architecture Framework for Device Single Sign On in Personal Area Networks

Fig. 2. Device SSO in a PAN

1373

Fig. 3. Client Server SSO in a PAN

vicinity of the ‘server’ device that is already turned on, needs to be logged in. An example would be the user entering into his office (where his ‘server’ is already logged in) with his PDA, which is not turned on/logged on yet. At this point of time, what normally happens is that the user is prompted with a login screen in the server and/or client side to provide the appropriate logins and password for device mutual authentication. According to the device SSO scheme though, this communication between the server and the client device should happen in a transparent way. For this purpose we propose an SSO scheme based on a service application that runs both at the server and at the client side as daemon application. While at the server side the service starts up after invocation by the server, on the client side it runs as part of the device boot up process. Upon discovery of the client device, the server performs a security handshake with the client to assure mutual authentication of the device. Once the mutual authentication part is carried out successfully, the server initiates the log on into the client device on behalf of the user. The client device is now formally logged in and part of the PAN. Authentication is thus established. Once signed on, the devices can communicate between each other securely, since mutual authentication is already done and a session key is established at the end of mutual authentication. The crucial issue that the SSO scheme has to take care of, is to guarantee that the mutual authentication is performed in a way that is both secure and takes also into account the limitations posed by the personal devices and the client-server model. For the security framework of the client server model we propose a Kerberos based SSO scheme. Assuming that the server has better and wealthier resources in terms of energy and computing power as compared to the clients in the network, we choose to put the burden of the authentication mechanism on the server side. For the authentication process we use the Kerberos protocol, which is hosted and executed by the server device. The SSO component consists of both the KDC and the TGS, running on the server machine. This can be in the form of two separate services running on the same system. In the following we briefly outline the Kerberos based PAN SSO scheme for the client server model. Before that, a short description of the conventions is provided.

1374

A. Chandershekarapuram et al.

c: client s: server Kx,y: A shared secret key between entities x and y. It is normally used for a session only and is also called a session key Tx,y: A Kerberos ticket Ac: An authenticator that is produced by the client Kx: The secret key of entity x n: A nonce or a time stamp that ensures the freshness of the message transmitted. The actual messages exchange is as follows: 1. Client → KDC: 2. KDC → Client: 3. Client → TGS: 4. TGS → Client: 5. Client → Server: where {•}K stands for the message • encrypted by the key K and Tc,tgs = where v is the validity period of the ticket. Initially the client communicates with the KDC service of the server to obtain a TGT. Along with the TGT, the KDC sends also the key that the client will use for the communication with the TGS. This key is sent to the client encrypted using the client’s secret key. Note that the client has his secret key generated from a password that the client provides to the KDC only the first time after the validity period expires. The storage of the password, the generation of the client’s secret key both at the client and the KDC side and the adjustment of the validity period, are all issues that our application takes care of. After the reception of message 2, the client has the decrypted key Kc,tgs. This key is then used to encrypt the Authenticator Ac. The Authenticator is of the form Ac,s={c, t, key}Kc,s. Once the TGS confirms the authenticity of the request it issues to the client the actual ticket that the client could use to start communication with the server. The client then provides to the server an authenticator encrypted with the session key Kc,s provided by the TGS along with the ticket. The server can authenticate the client by checking the Authenticator. If successful, the client can join the PAN. The basic difference of the proposed Kerberos based SSO scheme with the initial Kerberos protocol is that the device SSO scheme does not require the existence of any PKI infrastructure. On the contrary, since the devices in a PAN most of the times belong to the same user, it is reasonable to assume that the role of the trusted third party authority can be undertaken by a device within the PAN, namely the server device. Even in the case that not all of the PAN devices belong to the same entity, it is also reasonable to consider that there is a fair amount of trust between the participating devices, since the corresponding users consent to join their personal devices to form a PAN. Both the KDC and the TGS components reside in the server and can operate as daemon services in the background of the machine. Another advantage of the Kerberos based SSO scheme is that the synchronization requirement that is necessary in the Kerberos protocol can be better fulfilled in the

Architecture Framework for Device Single Sign On in Personal Area Networks

1375

context of a PAN, since personal devices within a PAN can be better and easier synchronized through the server device. Additionally, the validity period of the TGT ticket issued by the KDC component can be much shorter in the device SSO scheme. It is a usual case in PANs that devices join and leave the network in a rather high frequency, so it would be safer to issue a brand new TGT ticket in more frequent, regular time intervals. Besides that it is a well known fact that many attacks on the Kerberos protocol exploit the vulnerability of long ticket lifetimes, by replaying old tickets within the lifetime of a valid ticket. A typical duration of a ticket lifetime could be as long as eight hours [12]. To deal with such an attack by storing old valid tickets is not always easy because of the excessive storage requirements at the server side. However this problem in PANs can be easily dealt with by issuing TGT tickets on a more frequent basis. By appointing the device that will undertake the task of the SSO to be a desktop PC or a laptop, along with the use of the symmetric key primitives of the Kerberos authentication protocol makes it obvious that the power and other processing constraints can be significantly alleviated. 4.2 The P2P Model Now we discuss the SSO solution for a PAN network with peer-to-peer (P2P) model architecture. Since PANs are ad-hoc in nature, it makes more sense to deploy this type of architecture for a PAN, allowing thus for direct authentication and communication from any device to any other device in the network. For this reason the P2P architecture is the most popular and most widely used for PAN networks. An illustration of the P2P SSO is shown in Fig. 4. In the case of a P2P scenario, any device can be logged in by the user. This device could be then used to log on to other devices. Therefore in a P2P SSO scheme, each device has equal responsibility and can undertake the task of signing in any new device in the PAN. In the diagram shown in Fig. 4, P1 is assumed to be logged in, while the devices P2 and P3 are not yet logged in. We assume that the first peer P1 of the PAN is logged in by the user. This device has already authenticated the user/owner of the device. Assume that P2 is the new device that comes to proximity of P1. Our device SSO solution dictates that a service application will be running in both P1 and P2. Unlike the case of the client server model, in this case both peers have to run this service at the boot up process, since it is not known in advance which of the peers is going to log on to which. P2 being at the vicinity of P1 detects P2 and initiates mutual authentication for both the devices (action 1). If the authentication handshake is successful, the new device completes signing in the network (action 2). Now the states of both P1 and P2 are identical. This is because both of them have been logged in and are thus in the same state, behaving as two ‘peers’ of the PAN. In order to completely maintain a consistent view for the user, a connection is made back from the new device (P2) to the already logged in device P1 (action 3). Now there exists a bidirectional link between both the devices. Suppose now that a third device P3 comes into the vicinity of both P1 and P2. P3 now needs to be logged in by an already logged in device. This could be either P1 or P2. In the illustration P1 is shown logging into the device P3 (action 4). After the authentication mechanism is complete the new device

1376

A. Chandershekarapuram et al.

logs in to its OS (action 5). The new device makes then a connection back to P1 and establishes a bidirectional link with all the other logged in devices (actions 6, 7 and 8), which are mutually authenticated. Note that at the end of the whole sequence, a user would not be able to distinguish between which device was logged in first and which one was last thus making every device to be a peer of every other device in the network. Unlike the client server model where the bulk of the work for authentication is done at the server side, in the P2P model both the devices take equal responsibility in the mutual authentication mechanism. For this purpose we chose not to use a Kerberos server running at each node and authenticate the incoming clients for oneway connection, since such a solution would demand a lot of computing power at each node. Instead, the solution that we adopted for the mutual authentication mechanism was similar to the one that is used for the authentication between two Bluetooth devices. This is a more tangible solution that also incorporates symmetric key primitives to make the overall authentication scheme lightweight and suitable for handheld devices. Fig. 5 provides an illustration of the modified Bluetooth basic authentication mechanism proposed for the P2P SSO architecture. We assume that a pair of devices, A and B, shares a secret key K AB before they actually start being part of the network. Although such an assumption is not always applicable, the limited size of a PAN makes it feasible. The duty of specifying, managing and updating the symmetric keys is carried out by the application itself. Let also MAC be the Message Authentication Code that is generated using the secret key, Ks the secret key for a session s, t a timestamp and Knew the authentication key for a new session. Both devices generate a random number RA and RB respectively. These are generated at the local system and cannot be reproduced by any other entity. The random numbers are then sent to the other node (action 2). The message contains the random number encrypted using the key KAB. This key is used only for the first time that the two nodes communicate. A MAC is also provided to prove the integrity of the message. The key used for this MAC is the same as that of the key used for encryption. This is the case in order to reduce the number of keys associated with a node. It should be noted that the time stamp could either be the current time in the machine or a nonce which is incremented each time a communication is initiated. The latter is a simpler option since it does not involve timing and synchronization issues. Upon receiving the MAC, each node checks the integrity of the message and if the integrity check is passed, the random number is decrypted (action 3). At this point both node A and node B obtain the random numbers RB and RA respectively. Now, the two nodes can independently calculate the key for their session by doing some kind of a scrambling operation (denoted in the figure as ⊕). This operation can be as simple as XOR-ing the two values or using an algorithm such as E21. The new value of KS will be KS = RB⊕RA and this will be the session key for the current session (action 4). To further verify the use of this session key, both nodes encrypt and send to the other parties a random number using the new session key. Since the use of the same KAB for encrypting the random number during each run is not safe enough, it would be better to use a new key, being a combination of the initial key KAB and the previous session key, such as KNEW = KAB ⊕ KS.

Architecture Framework for Device Single Sign On in Personal Area Networks

Fig. 4. Peer-to-Peer SSO in a PAN

1377

Fig. 5. The proposed P2P Authentication protocol

Comparing the two SSO schemes, it is obvious that the SSO client server model is conceptually easy and its design and implementation are easier than the corresponding P2P SSO. Key management is also easy in the sense that all that the server has to bother is to have a key for each client of the system. At the same time, a client needs only one key to share with the server. Secure communication can be established between two clients (more than one hop) easily by using the client server model. Additionally, there are no issues regarding association in such a system since the server always acts as the master. However, it is obvious that in the client-server SSO model, a device assuming the role of the server must be in place beforehand so that the whole system is functional. In case of absence of the server device, two devices cannot perform the sign-on even if they are in the vicinity of each other. Furthermore, the design of the client-server SSO model is very static in nature, in the sense that the system is preconfigured with one server and all other as clients. If the server is not in range the client devices cannot sync. However, this is a limitation posed by the client server network architecture and not by the SSO scheme itself. On the other hand, the P2P model implements SSO in the true sense, since any device can sign on to any other device. Any subset of devices can engage in SSO and join or form a PAN. This is not possible in the case of a client server model since a server should be appointed for managing SSO functions. The P2P SSO model however is more difficult to implement. Since currently there are not so many APIs built in for a peer-to-peer model, one should have a client server based model tuned to work as a peer-to-peer one. In addition, key management is an issue, since each peer must posses or negotiate beforehand a secret key with every other peer, hindering thus the scaling of the network.

5 Our Application In order to test and evaluate the proposed device SSO schemes, we developed a custom application. This application was developed on top of Java to take advantage of the level of abstraction from hardware that it provides and use it as middleware for

1378

A. Chandershekarapuram et al.

our application. Alternatively, another solution would be to build the application on top of Linux, running on a PDA or laptop and then port the necessary drivers for the radio link. However, Java provides a friendlier user environment, allowing to concentrate on the application development itself and this is why we decided to use it as a basis for our application. Additionally, Java offers a large variety of wireless APIs, enabling us to integrate the application in a heterogeneous environment with multiple short range wireless technologies, such as Bluetooth and Wi-Fi. For the implementation of the client server and P2P SSO schemes, we used both J2ME and J2SE [3]. Particularly, the client server model was implemented using two USB Bluetooth Dongles. One of the Dongles was connected to a Dell Precision desktop PC and the other one on a Compaq Presario 2100 series laptop. The development environment was Java 2 Standard Edition. The necessary Connected Device Configuration (CDC) and Mobile Information Device Profile (MIDP 2.0) needed for the Bluetooth protocol stack, were provided by the software vendor Atinav [13]. For the P2P model additionally, the J2ME Wireless Toolkit 2.2 with MIDP 2.0 support was used to simulate the two mobile phones with Bluetooth Connectivity.

6 Conclusions In this paper we discussed and investigated the issue of Device Single Sign On in Personal Area Networks. Device SSO can prove very helpful in order both to secure and reduce the overhead of managing a PAN during the authentication process. However, several issues have to be addressed in a rigorous manner when designing a device SSO scheme. These issues have to do mainly with the high level of heterogeneity that a PAN environment introduces. The use of Symmetric key primitives is recommended for such an environment since today’s technology does not support high computational capabilities on handhelds which makes the use of PKIs impractical. We have developed two models for SSO on handheld networks, which are designed for specific scenarios, depending on the network model architecture that a PAN deploys. The Client-Server SSO is designed mostly for signing in a home/office environment where the client server model is more popular. The Peer-to-Peer SSO scheme provides signing in more dynamic environments, where the user is on transit and PANs are created dynamically and spontaneously. The security framework of the client server SSO is based on a variation of the Kerberos authentication protocol, whereas the corresponding one of the P2P SSO on Bluetooth authentication primitives. Both schemes perform mutual authentication using symmetric key cryptography to tackle the energy resource constraints of PANs. The two proposed PAN SSO schemes were implemented based on a custom prototype application.

References [1] Michael Kelly, “Is Single Sign on a Security Risk?” Version 1.2e, © SANS Institute, June 2002, SANS Institute, GIAC Certified Student Practical [2] Andreas Pashalidis and Chris J. Mitchell, “A Taxonomy of single sign-on systems,” Information Security and Privacy, 8th Australasian Conference, ACISP 2003, Wollongong, Australia, July 2003

Architecture Framework for Device Single Sign On in Personal Area Networks

1379

[3] Enrique Ortiz, “A Survey of J2ME Today,” October 2004 [4] Liberty Alliance Specifications, www.projectliberty.org [5] David P. Kormann and Aviel D. Rubin, “Risks of the Passport Single Sign on Protocol,” Computer Networks, Elsevier Science Press, volume 33, pages 51-58, 2000. [6] Andreas Pashalidis and Chris Mitchell, “Using GSM/UMTS for Single Sign-On,” Proceedings of SympoTIC '03 Joint IST Workshop on Mobile Future Symposium on Trends in Communications, Bratislava, Slovakia, Oct. 2003, IEEE Press, pp. 138-145 [7] Andreas Pashalidis and Chris J. Mitchell, “Single Sign-On using Trusted Platforms,” Information Security, 6th International Conference, ISC 2003, Bristol, UK, October 2003 [8] http://shibboleth.internet2.edu/ [9] Jongil Jeong, Dongkyoo Shin and Dongil Shin, “An XML-based Single Sign-On Scheme Supporting Mobile and Home Network Service Environments,” IEEE Transactions on Consumer Electronics, Vol. 50, no. 4, pp. 1081-1086, Nov. 2004 [10] William Josephson, Emin Gun Sirer, Fred B. Schneider, “Peer-to-Peer Authentication with a Distributed Single Sign-On Service,” Peer-to-Peer Systems III: Lecture Notes in Computer Science 3279, pp. 250-258, 2004 [11] Christian Gehrmann, Kaisa Nyberg, Chris J. Mitchell “Manual authentication for wireless devices,” Cryptobytes, Vol. 7, no. 1, Spring, 2004, pp. 29-37 [12] Bruce Schneier, “Applied Cryptography: Protocols, Algorithms and Source Code in C”, Second Edition, John Wiley & Sons, Inc.,1996 [13] www.atinav.com [14] RFC 1510, The Kerberos Network Authentication Service (V5), www.ietf.org/rfc/ rfc1510.txt