Key Management for Heterogeneous Ad Hoc Wireless Networks

Transcription

1 Key Management for Heterogeneous Ad Hoc Wireless Networks Seung Yi Robin Kravets Department of Computer Science University of Illinois at Urbana-Champaign 1304 West Springfield Avenue, Urbana, IL USA seungyi, Report No. UIUCDCS-R , UILU-ENG July, 2002

2 Key Management for Heterogeneous Ad Hoc Wireless Networks Abstract PKI has been recognized as one of the most successful and important tools for providing security for dynamic networks. However, providing such infrastructure in ad hoc wireless networks is a challenging task due to the infrastructure-less nature of ad hoc networks. In this paper, we present these challenges in detail, identify the requirements for such solutions in ad hoc networks, and propose a practical solution to provide certification services in ad hoc networks. We employ threshold cryptography to distribute the CA functionality over specially selected nodes based on security and physical characteristics of the nodes. The selected mobile nodes that collectively provide PKI functionality are called MOCA(MObile Certificate Authority)s. Using these MOCAs, we present an efficient yet effective communication protocol for mobile nodes to correspond with MOCAs and get certification services. Results from our simulations verify the effectiveness of our approach, as well as the cost in terms of control overhead and delay. we also provide some insights into configuring such security services. 1 Introduction Since its birth more than two decades ago[12], public key cryptography has been recognized as one of the most effective mechanisms for providing fundamental security services including authentication, digital signatures and encryption. Effective management of digital certificates is one of the key factors for the successful wide-spread deployment of public key cryptography. PKI (Public Key Infrastructure), an infrastructure for managing digital certificates, was introduced for this purpose. The most important component of PKI is the CA (Certificate Authority), the trusted entity in the system that vouches for validity of digital certificates. Success of PKI depends on the availability of the CA to the principals in the system or the nodes in the network since a principal must correspond with the CA to get a certificate, to check the status of another principal s certificate, to acquire another principal s digital certificate, and so on. PKI has been widely deployed for wired networks and some infrastructure-based wireless networks. Since good connectivity can be assumed in such networks, the main thrust of research in such environments has focused on the availability of the CA and the scalability of the CA to handle a large number of requests. However, it is still unclear if such approaches can be extended to ad hoc networks. Connectivity, which was assumed to be good in previous PKI solutions, is no longer stable in ad hoc networks. Unfortunately, maintaining connectivity is one of the main challenges in ad hoc networks, since the inherent infrastructurelessness of ad hoc networks makes it hard to guarantee any kind of connectivity. Another serious problem present in ad hoc networks is the physical vulnerability of the nodes themselves. Considering that most ad hoc networks will be deployed with mobile nodes, the possibility of the nodes being captured or compromised is higher than in wired networks with fixed hosts. Mobile nodes in a infrastructure-based wireless networks have the same vulnerability, but they can rely on the infrastructure for detection of compromised nodes and potentially some help with recovery. With an infrastructure-based solution, the mobile nodes may store all sensitive information in the infrastructure and maintain minimal information in the device. Since there is no stable entity in an ad hoc network, the vulnerability of ad hoc nodes is even higher. Currently proposed solutions for providing PKI for ad hoc networks address the physical vulnerability of the nodes by employing the distribution of CA functionality across multiple nodes and using threshold cryptography[13]. These approaches also increase the availability of CA. The first challenge in such approaches is the problem of picking which nodes should be a part of the distributed CA. A random set of nodes from a network can be chosen to play the role of CA. Such a random choice may not be the best way to pick the nodes that affect the security of the wholenetwork. The second challenge is how to provide 1

3 efficient, yet effective, communication between the mobile nodes and the CA nodes to create the illusion of an available CA, even in dynamic networks with possible compromises or partitions. To this end, we present the MOCA (MObile Certificate Authority) approach. A MOCA is a mobile node within an ad hoc network selected to provide distributed CA functionality. MOCAs are chosen based on an observation of heterogeneity within an ad hoc network. Physically more secure and computationally more powerful nodes are the typical choices for MOCAs. These selected MOCAs uses threshold cryptography to share the CA functionality and provide services with high availability. The client nodes are equipped with our certification protocol MP(Moca certification Protocol) that enables them to contact sufficient MOCAs in an efficient and also effective way. We demonstrate the effectiveness of our protocol with extensive simulation. Based on the simulation results, we also provide certain insights into how to configure such security services for ad hoc networks. The remainder of this paper is organized as following. In Section 2, we present a detailed description of the key management problem in ad hoc wireless networks. We define the important metrics for designing such framework and use these metrics to evaluate some of existing research. In Section 3, our approach using MOCA is presented in detail. Section 4 presents simulation results from our implementation. Section 5 suggests some of possible extension of this work and we conclude in Section 6. 2 Key Management in Ad Hoc Networks The main idea of public key cryptography is to bind a principal with a pair of inter-related keys. One of the two keys is meant to be open to the public, thus called the public key, and the other is supposed to be kept in possession of the principal only, thus called the private key. By using this pair of keys, principals can authenticate each other, generate digital signatures for messages, or encrypt sensitive data or participate in secure communications. One of the biggest benefits of public key cryptography is that the private part of the key pair is never out in the public. In comparison, symmetric cryptography requires communicating peers to exchange or set up a shared key between them before actual communication. This step is usually the most vulnerable phase in symmetric cryptography. To securely guarantee the binding between the principal and the key pair, digital certificates were introduced. A digital certificate is cryptographically signed proof of the binding between a principal and its public key. To manage digital certificates, an infrastructure, the PKI was introduced, providing services that generate, distribute and revoke digital certificates using a trusted third party called the CA. Although the PKI has been successfully deployed in wired and infrastructure-based wireless networks, it is yet unclear if the same approach will also prevail in ad hoc networks. In this section, we present the challenges to providing key management services in ad hoc wireless networks in detail. We also present the criteria to design and evaluate key management frameworks for ad hoc networks and evaluate some existing approaches with these criteria. 2.1 Certificate Authority Services CA provides four major certification services: certificate issuing, renewal, revocation and certification directory service. In response to authenticated requests from a client, the CA issues a certificate that is bound to the client s public key. Note that the original authentication of the client to the CA must be done outof-band. In currently deployed PKI solutions, this step usually requires users to carry passwords or some security devices like smart cards. If the certificate carries an expiration date, the client may request the CA to renew the original certificate, again based on authentication of the client to the CA. The CA also has the power to revoke a certificate. Effective certificate revocation is not yet well understood and is currently 2

4 being investigated for all types of networks[8]. Beyond managing certificates, it is also the CA s responsibility to disseminate the public keys of principals to inquiring clients. Every response from the CA is signed with the CA s private key, and so can be validated with the CA s public key. The success of this approach lies in maintaining the secrecy of the private key of the CA. It is also necessary for the CA to remain on-line (i.e. available) to provide these services. There are three major parameters to a distributed key management framework: fault tolerance, how many node failures the system can handle, vulnerability, how many compromised nodes the system can withstand, and availability, whether the client can contact the required number of CAs. Unfortunately, the optimization of any one of these parameters may adversely affect other parameters and so adversely affect the success of the system. In addition, mobile networks present hostile environments where nodes may easily die or be compromised and no guarantees can be made about the ability to access the necessary nodes for authentication. One of the natural questions regarding the necessity of a distributed key management service is: Can we replace this heavy-weight service through the advance deployment of public keys to each client so that the client does not have to contact the CAs? Although it is possible to do so, a system built in this way is very static. It is not trivial to add a new node to the operating network or to remove a misbehaving node from a network. On every such occasion, the updated information must be propagated to all the nodes in the network in a timely manner to prevent possible attacks. Also, considering the size of mobile devices in the ad hoc networks, storing the certificate of every user of a possibly large network can challenge the available resources of the mobile node. An ideal key management service for ad hoc networks should provide the best of both worlds: it must be light-weight and simple to mobile nodes, and it must be available in highly dynamic networks. In the rest of this section, we investigate existing approaches toward achieving these goals, evaluate some limitations and suggest potential improvements. 2.2 Single CA Case The simplest approach to providing CA functionality in an ad hoc network is to assign one node to be the CA. The success of this scheme now depends on that single CA node. This approach is not fault tolerant, since the failure of one node breaks the system. Similarly, this approach is highly vulnerable, since an adversary need only compromise one node to acquire the secret key. Finally, given the expected mobility and unpredictability of ad hoc networks, it may be possible that nodes will not be able to reach the CA in a timely fashion, making availability very unpredictable. Therefore, it is not very likely that a single CA can effectively service the whole ad hoc network. 2.3 Fault Tolerance Nodes in an ad hoc network are expected to be light-weight, low power mobile nodes that have a limited lifetime. As such, it is necessary that the key management system be tolerant to some potential node failure. Having a single CA node can be a serious fault tolerance problem for the whole network. To provide better fault tolerance, it is possible to deploy many copies of the CA in the network. With many such replicas, the system can withstand (number of replicated CAs - 1) failures because the CA service is available as long as there is at least one operational CA. Availability has also been improved since a client node will have a better chance of reaching one of the multiple CAs to get service. Unfortunately, the system has become more vulnerable. An adversary need only compromise one of the many CA nodes to acquire the secret key and so compromise the whole system. In comparison, the 3

5 adversary has only a single target in single CA scenario so an adversary must locate the single CA to compromise it. Using replicated CAs makes it easier for the adversary to locate a target and compromise the whole system. Therefore, using replicated CAs is not a viable solution in ad hoc networks. 2.4 Vulnerability The problem of using replicated CAs stems from the fact that each replica has full knowledge of the system secret. The approach is vulnerable against any attacks that compromise a single replica, which should not be considered too difficult considering the inherent physical vulnerability of mobile nodes. To combat this problem, more intelligent ways of distributing the CA functionality have been proposed. Most of the proposed solutions take advantage of a cryptographic technique called Secret Sharing proposed by Shamir[2]. With secret sharing, a single secret can be divided into n parts and distributed across n nodes. To reconstruct the secret, any node must collect any k pieces of the secret. With k out of the n pieces, the node can then reconstruct the whole secret. This approach has been applied to cryptographic keys and is called Threshold Cryptography[4]. In threshold cryptography, a key used for encryption is divided into n pieces, and any k pieces can reconstruct the complete key. However, one drawback of threshold cryptography is that the secret key can be fully reconstructed at the any node that acquires k pieces of the key. If the node is compromised while it carries the full key, the system secret could be compromised. The Threshold Digital Signature scheme was proposed to address this problem[11]. With threshold digital signatures, again the key is divided into n pieces and distributed. But now if a client needs a signature on its data, each secret holder will use its piece of the key to generate a partial signature over the data. When client collects k of these partial signatures, the client can reconstruct the full signature. In this way, the actual secret key is never reconstructed at any point and does not travel through the network. Applying the concept of secret sharing to ad hoc networks has been suggested, but never evaluated in detail[13]. However, this approach has been applied to wired networks in COCA, a secure distributed on-line certification authority providing fault tolerance [14]. COCA uses replication to achieve availability and proactive recovery and threshold cryptography to combat mobile adversaries[5]. Each COCA server has a piece of the CA s private key, and clients need to contact a quorum of COCA servers to get the CA s full signature. COCA is a framework designed toward an environment like the Internet or a LAN where the connectivity is good and nodes have sufficient resources. For ad hoc networks, a solution that is lighterweight and also very adaptive to changing environment would be more desirable. 2.5 Availability Even after achieving an adequately secure CA deployment using threshold digital signature techniques, there still remains one problem. This set of secure distributed CA nodes should be highly available for the client nodes in the network at all times. In ad hoc networks, there is no guarantee of connectivity between any two nodes at any point in time. Even though the distributed CAs are secure and on-line, it does not mean that nodes will be able to reach the CA, potentially due to network disconnection or contention. This presents a challenge to the availability of the CA(s). In order to increase the availability of the CA(s), it has been proposed to distribute the CA functionality over all nodes participating in an ad hoc network. For example, in [7], every node carries a piece of the CA s secret key. By using threshold cryptography, a node only needs k nodes in its neighborhood to achieve authentication using one hop broadcast. This approach has the advantages of high availability at all times, and low communication overhead due to the one hop broadcast-based operation. However, if k is set to a relatively low number compared to the total number of nodes in the network (which in turn is equal to the number of CA nodes in the network), compromising k nodes around a victim node is a relatively easy task. Although the authors propose proactive secret updates 4

6 as a solution to address this problem, it is still not clear if that can eliminate the possibility of enough CA nodes getting compromised and hence the whole system. It is a challenging task to design a distributed key management framework for ad hoc networks that satisfies all three criteria discussed in this section. In the next section, we propose our approach for this problem using MOCAs in detail. 3 Practical Key Management Framework for Ad Hoc Networks The expected heterogeneity of ad hoc nodes and the users of ad hoc nodes can benefit a key management framework by providing some nodes with higher security levels, better physical security and more computational resources. Given this observation, we present a practical key management framework for ad hoc networks based on the use of MObile Certificate Authority(MOCA). In this section, we first discuss the impact of such heterogeneity. Next, we describe the use of threshold cryptography and present our Moca certification Protocol (MP) using both flooding and several unicast optimizations. 3.1 Trusted Nodes An ad hoc network is expected to have a wide variety of nodes with differing computational power as well as differing levels of physical security. Essentially, nodes in a network can be heterogeneous. Based on this heterogeneity assumption, it is interesting to consider distributing the CA functionality only to relatively secure and relatively powerful nodes. Consider a military scenario where each node is associated with a person of a specific rank, with the assumption that higher ranked nodes receive better physical security. Also, in non-military situations, consider a school field trip where students want to communicate with each other securely. Teachers in the group can volunteer to form a distributed CA. Similar situations can be imagined in conference rooms in companies, in wildlife expeditions and any other situations where ad hoc networks can be useful. A very simple guideline would be to choose the most physically secure nodes with maximum resources that are less prone to compromises or failure. Choosing the MOCAs from a subset of nodes in the network may appear as limiting the maximum number of MOCAs in the system, which may affect the probability of compromising enough MOCAs to bring down the system. For example, among 300 nodes, a network operator may have the choice of selecting 100 random nodes to distribute the CA functionality or identify 30 more secure nodes and let them constitute the distributed CA. If we blindly compare the number of MOCAs in the system, the first approach looks better. But, if we can guarantee an adequate level of physical security of 30 MOCAs in the second case, compromising them can be made much harder than compromising the randomly selected MOCAs in the first case, hence making the second case more secure against adversaries. In the previous section, we established that the key management framework for ad hoc networks should be tolerant to faults, protected against the inherent vulnerability of mobile nodes, and available for nodes in the network that changes dynamically. By deploying the CA functionality based on this heterogeneity assumption, we can achieve higher fault tolerance due to the inherent security of the selected nodes, stronger protection against vulnerability due to decreased probability of compromise or failure of these selected nodes. It is possible that an ad hoc network does not have enough heterogeneity among the nodes, which may make it difficult if not impossible to choose MOCAs based on this heterogeneity assumption. In such cases, we can fall back to random sampling to choose MOCAs. Our protocol still works as designed but the level of security will decrease since there is no guarantee on the security of each MOCAs. 5

7 3.2 Threshold Cryptography In our framework, among M mobile nodes in a given network, n nodes are chosen based on the security and physical characteristics of the nodes. These n nodes are called MOCA (MObile Certificate Authority) nodes and they collectively provide the functionality of a CA to the whole network. Using threshold cryptography, these n MOCAs share the CA s private key and any set of k MOCAs can reconstruct the full CA key. To prevent the CA s private key from being reconstructed at any point of time, threshold digital signatures are used[11]. Any client requiring a certification service must contact at least k MOCAs with its request. The contacted MOCAs each generate a partial signature over the received data and send it back. The client needs to collect at least k such partial signatures to reconstruct the full signature and successfully receive the certification service. The total number of nodes in the network, M, is a given number. Although M can change dynamically over time, it is not a parameter that can be controlled by a network operator. The number of MOCAs, n, is determined by the characteristics of nodes in the network, such as physical security or processing capability. The number of secure nodes is also not a parameter the network operator can set. For the school field trip example, M is the total number of students and teachers and n is the number of teachers. Although these values are defined by the characteristics of the system and can change over time, they are not parameters that can be controlled by our system. In fact, they define the limits of the system as an upper bound for k, the crypto threshold. Given predefined M and n, the last parameter k, the threshold for secret recovery, is indeed a parameter that the network operator is free to set. Once k has been chosen and the system deployed, it is expensive to change the value of k. Therefore it is important to understand the effects of different values of k for a given system. It is clear that no one value will fit all systems, so our goal is to provide some guidelines for choosing k. To make our protocol more adaptive to varying network configurations, we will introduce additional tunable parameters in the next section. k can be chosen between 1 (a single CA in the whole network) and n (a client needs to contact all MOCAs in the system to get certification services). Setting k to a higher value has the effect of making the system more secure against possible adversaries since k is the number of MOCAs an adversary needs to compromise to collapse the system. But at the same time, the higher k value can cause more communication overhead for clients since any client needs to contact at least k MOCAs to get certification services. Therefore, the threshold k should be chosen to balance the two conflicting requirements. 3.3 Certification Protocol Given the threshold value, k, the total number of nodes, M, and the number of MOCAs, n, next step is to provide efficient and effective communication between clients and MOCAs. The communication pattern between a client and k or more MOCA servers is one to (k or more) then back, which means that a client needs to contact at least k MOCAs and receive replies from each of them. To provide an efficient way of achieving this goal, we propose a certification protocol called MP (Moca certification Protocol). In MP, a client that requires certification services sends Certification Request (CREQ) packets. Any MOCA that receives a CREQ responds with a Certification Reply (CREP) packet containing its partial signature. The client waits a fixed period of time for k such CREPs. When the client collects k valid CREPs, the client can reconstruct the full signature and the certification request succeeds. If too few CREPs are received, the client s CREQ timer expires and the certification request fails. The client is left with the option to initiate another round of certification requests. As a CREQ packet passes through a node, a reverse path to the sender is established. These reverse paths are coupled with timers and maintained long enough for a returning CREP packet to be able to travel back 6

8 to the sender. If no CREP is returned within the time-out period, the reverse path entry in the routing table expires and is purged. If a CREP traverses back through the previously set-up reverse path to the sender, the routing table entries are refreshed and the bidirectional path remains in the routing table for certain amount of time for potential reuse. The management of routing information in the intermediate nodes and the use of reverse path forwarding of CREP packets are similar to on-demand ad hoc routing protocols like AODV[9] or DSR[6]. The CREQ and CREP messages are similar to Route Request(RREQ) and Route Reply(RREP) messages from these protocols. This similarity also presents a potential for our certification protocol and the existing on-demand routing protocols to benefit from each other by keeping the routing information in the nodes up to date, and also utilizing cached routing information from each other Flooding In our initial prototype, we used the simplest means of reliable data dissemination, flooding, to reach all MOCAs in the network[10]. As shown in previous results, while this flooding approach is effective, it generates quite a large amount of overhead traffic. First, the traffic generated from CREQ flooding is large. Second, since a client has no way to limit the dissemination of a CREQ, all the MOCAs that receive a copy of the CREQ respond with a CREP, making the client receive more than it actually needs to reconstruct the full signature. Note that a client only needs to collect k partial signatures to reconstruct the full signature. Any additional partial signatures are discarded and waste networking and processing recourses Unicast To reduce the amount of overhead from the flooding while maintaining an acceptable level of service, we introduce another method called -unicast. In -unicast, if a client has sufficient routes to MOCAs in its routing table, the client can use multiple unicast connections to replace flooding. This scheme takes advantage of existing routes, as seen in the routing table. Therefore, -unicast does not initiate new route discoveries. in the name represents the sufficient number of cached routes to MOCAs to use unicast instead of flooding. Blind use of unicast with insufficient cached routes can result in multiple instances of route discovery, which in turn causes multiple rounds of flooding. To prevent such a situation, our protocol only uses unicast when there is enough information cached in the routing table, otherwise it falls back to flooding. First, the client looks into its routing table and decides whether it has a sufficient number of cached routes to MOCAs. The crypto threshold k is the key factor to sufficiency. If the node perceives the network to be very stable with low mobility and is confident about the information in the routing table, having just k cached routes may be sufficient to initiate the multiple unicast CREQs and the client can expect to receive all k replies back. If the node perceives the network to be highly mobile and have unstable routes, just sending out k unicast CREQ is dangerous since even one loss of a CREQ or a CREP results in the failure of the whole certification request. In this situation, the node should send out an additional CREQs to increase the probability of success. is a marginal safety value to increase the success ratio of unicast and it should be determined based on the node s perception of the network status. How a node will perceive the status of network is out of the scope of this paper but any method available can be used. We call the sum of the crypto threshold k and the safety margin, the unicast threshold and represents it with, hence the name -unicast. Our previous work revealed that a client often has a moderate number of cached routes to MOCAs under reasonable certification traffic in the network[10]. One of the interesting questions is how to choose the MOCAs to contact among the ones cached in the routing table. If there are only k + cached routes in the table, it is simple that the client needs to contact each and every one of them. But if there are more than 7

9 the sufficient number of routes in the cache, the choice of which ones to use can affect performance. We define three different schemes: 1. Random MOCAs - Random k MOCAs in the routing table are picked. 2. Closest MOCAs - By using the hop count information stored in the routing table, k + MOCAs with smallest hop counts are used in this scheme. Intuitively, this approach has the benefit of the shortest response time and the smallest packet overhead since the CREQ packets travel the least distance. 3. Freshest MOCAs - Among the MOCAs in the routing table, the most recently added or updated k + entries are used for -unicast. This approach is least vulnerable to possible stale routes in the route cache, especially under high mobility. If there are more than stale routes among the chosen MOCAs, the whole certification request fails and the client should fall back to flooding, which will cause even more overhead. By choosing the freshest MOCAs, the client can minimize the risk of such failure. We will provide simulation results from each of these schemes in the next section. 4 Evaluation The cost of a certification protocol can be evaluated using the two metrics: control packet overhead and additional communication delay caused by the certification process. We evaluate the effectiveness of our approach by simulating our protocol under various configurations. The simulations demonstrate that our approach is practical for ad hoc networks providing adequate service availability without incurring prohibitive overhead. By evaluating the results of the simulations, we provide some insight into how to configure the MOCA networks to achieve efficiency and availability at the same time. For all simulations, there are three parameters that can be tuned according to the network configuration. Time-out Threshold - is used by a client to decide how long it should wait for replies after sending out a certification request. affects the success ratio and additional delay caused by the certification process. If the client receives enough CREPs within, the whole certification request is a success and the client can go on to the next step of actual secure communication. If the client waits for but still does not receive enough CREPs, that certification request is a failure. The client can either initiate another certification request or report the failure to the application and let it decide the next action. Larger values can increase the possibility of success since the node waits longer for the CREPs to come back. If there are not enough CREPs on their way back, the certification request will eventually fail and larger values can cause the node to needlessly wait longer. On the other hand, if is set too small, even when there are enough CREPs on their way back to the client, the client may make the decision of failure and give up too soon. Crypto Threshold k - k is the minimum number of CREPs required for a client to reconstruct the MOCA s full signature and render the certification request successful. The choice of k affects the security of the whole framework and at the same time the general success ratio. If k is set low, a client only needs to collect k partial signatures to continue. Thus the success ratio increases but at the same time an adversary only needs to compromise a small number of MOCAs to compromise the framework. A small k also makes the framework more vulnerable to attacks. High k values can make attacks difficult, but the burden on clients also increase since a client needs to contact a large number of MOCAs for any certification request. 8

10 Unicast Threshold - When unicast-based approaches are used, sending out the minimum k of CREQs by unicast may not be a good choice since the client cannot afford to lose any of the k CREQs or the k CREPs coming back. To make the protocol more robust in a dynamic network and also against the potential staleness of cached routes, we adopt the policy of sending additional CREQs when using unicast-based approaches. The unicast threshold is the sum of the crypto threshold k and the margin value. As describe above, the choice of k can affect the security of the whole framework so k should be chosen first. Then, according to the mobility and dynamicity of the network that affects the validity of cached routes, an adequate value of can be chosen to compensate for mobility. Larger values make it more difficult for a client to use the more efficient unicast-based approaches because the client must have k cached routes to MOCAs in its routing table at the time of the certification request. If the client has that many cached routes, the client can afford to lose up to CREQs or CREPs and still collect k CREPs to continue. Setting to a low value makes it easier for a client to use unicast-based approaches but may cause an excessive amount of certification failure due to loss of too many CREQs or CREPs in the process. We present some insights on how to choose each of these tunable parameters at the end of this section after presenting the simulation results in detail. 4.1 Simulation Set-Up To evaluate our approach, we implemented our prototype certification protocol in the ns-2 network simulator[1]. Node movement follows the random waypoint mobility model implemented in the CMU Monarch extension[3]. Table 1 shows detailed simulation parameters. Table 1: Simulation Parameters Total Number of Mobile Nodes 150 or 300 Area of Network 1000m x 1000m Total Simulation Time 600 seconds Number of Certification Requests 10 requests each from 100 or 200 non-mocas Node Pause Time 0, 10 seconds Node Max. Speed 0, 1, 5, 10, 20 ms For the certification request pattern for 150-node scenarios, 100 non-moca nodes each make 10 certification requests randomly distributed through the whole simulation. This adds up to total of 1000 certification requests during 600 seconds. For 300-node scenarios, 200 non-moca nodes make 10 certification requests each, adding up to a total of 2000 certification requests. This is roughly 100 or 200 requests per minute and we believe that this is a reasonable number if not too pessimistic. Each requesting node is making one request per minute on average during the course of simulation. Assuming each certification request precedes initiation of a new secure communication, starting one secure communication session every minute should be more than adequate for ordinary mobile nodes. Our simulation results show consistent results over different pause time, speed patterns and also number of MOCAs. Therefore in this section we only present the results using 0 second pause time, 10 m/s maximum speed and 30 MOCAs. 4.2 Unicast-based Certification Protocols To evaluate the effects of employing unicast in our design, we first present results from a pure flooding-based approach[10]. Figure 1 shows the number of CREPs received per CREQ. 100 non-moca nodes make a 9

11 Static Network pause=10s,speed=1m/s pause=10s,speed=5m/s pause=10s,speed=10m/s pause=10s,speed=20m/s pause=0s,speed=10m/s pause=0s,speed=20m/s Occurences No. of CREPs Received Figure 1: No. of Received CREPs using Flooding total of 1000 certification requests. Since flooding is used, all MOCAs reply with a CREP if they receive a CREQ. The different lines represent varying mobility patterns. Under a static network, represented by the solid line, the flooding-based approach works very well. Almost all the CREQs reach all 30 of MOCAs and most CREPs make their way back to the client. The reason some of the CREPs get lost (there are many occurrences of nodes receiving 25 to 29 CREPs) is due to temporary network contention caused by the reverse packet storming effect generated by multiple CREPs traveling back to the client at almost the same time. As can be observed from the graph, setting k to be 15 or 20 can result in more than a 90% success ratio for certification requests and proves that flooding is indeed a very effective means of eliciting responses in ad hoc networks Flooding beta=5 beta=10 beta=15 beta=20 beta=25 Occurences No. of CREPs Received Figure 2: No. of Received CREPs using Closest-Unicast Figure 2 shows one of the unicast-based approaches, Closest-Unicast, with varying values of the unicast 10

12 threshold. Figure 2 also has one line for the flooding-based approach for comparison. Consistent with the previous figure, the flooding line has a very high bump around 30, which is the number of MOCAs in the network. Each Closest-Unicast line has two bumps: one at and another at 30. The bump around shows that unicast is being used and works well. For this particular example, the usage of unicast is shown in Table 2. Table 2: Usage of Unicast Flooding Use of Unicast CREQs Use of Flooding CREQs Total No. of CREQs Table 2 presents the total number of requests made as well as the number of requests using flooding and unicast. Note that use of unicast CREQs decreases with higher values, causing the height of unicast bumps in Figure 2 to decrease as increases. This decrease is due to the fact that for higher values, it is more likely that not enough routes to MOCAs will be cached in the routing tables Flooding Random-Unicast Closest-Unicast Freshest-Unicast 140 Occurences No. of CREPs Received Figure 3: No. of Received CREPs using Various Unicast-based Approaches, = 15 Figure 3 presents various versions of the unicast-based approaches in comparison with each other under one example mobility scenario. The unicast threshold is set to 15. We can observe that Closest-Unicast performs best with most success with unicast CREQs. Closest-Unicast also induces the least amount of overhead among the three unicast-based approaches as shown in next subsection. For the rest of the section, we use Closest-Unicast as our example except when providing a comparison between the unicast approaches. 4.3 Control Overhead In this subsection, we evaluate communication overhead, as measured by the total number of control packets used for certification services. 11

13 Table 3: Control Packet Overhead, n = 30 Number of Packets CREQ CREP Total Ratio to Flooding (%) Flooding Random-Unicast = = = = = Closest-Unicast = = = = = Freshest-Unicast = = = = =

14 Table 3 shows the overhead from flooding and various unicast-based approaches under varying unicast thresholds,. Generally, unicast-based approaches save 5 to 20 percent of control packet overhead. As the node chooses unicast more aggressively with lower, the savings are increased. Note that when is 20 or 25, there is little improvement over flooding. In this case, is very high and unicast is not used often in the simulations since not many nodes have that many cached routes to MOCAs. This causes most of certification requests to fall back to flooding, generating a similar amount of overhead as in flooding. Also, the amount of traffic generated by unicast CREQs increases as increases, adding more overhead. In a more reasonable scenario of 15 or less, unicast-based approaches save between 15 to 30 percent of overhead compared to flooding. Setting the unicast threshold as low as possible results in the best improvements in overhead but has the adverse effect of implicitly lowering the upper bound of crypto threshold k to, endangering the security of the whole framework. 4.4 Certification Delay The most frequent use of a certification service is to acquire the communicating peer s public key certificate. The delay to get the certification service must be added to the start-up latency of any secure communication. Thus, the time to finish the certification service should not be too long so a client can receive an adequate level of service within a short period of time. Also, the client should be able to determine failure as soon as possible so that it does not have to waste time waiting on failed requests. Figure 4 shows the distribution of arrival times of CREP packets with the Closest-Unicast approach with varying under a moderate mobility pattern of 0 pause time and 10 ms maximum speed. Also, a line for flooding is presented for comparison. Over all cases, the lines flatten out quite quickly within 0.3 seconds, indicating that a client can reasonably expect to receive all pending CREPs within 0.3 seconds from the time it makes a certification request. If the client does not collect enough CREPs within that time, the chances are very slim that enough CREPs are in in-flight to arrive later and fulfill the certification request. So, based on a appropriately chosen time-out threshold, a client can operate efficiently without wasting time. From Figure 4, the appropriate time-out threshold appears to be around 0.3 seconds. To get a better understanding of this graph, Figures 5 and 6 show a more detailed look at two of the lines from Figure No. of CREPs Received Flooding beta= beta=20 beta=15 beta=10 beta= Time (sec) Figure 4: No. of CREPs received over the course of time, using Closest-Unicast 13

15 7 9 0/ 1 -.,, +* * ( ) !" #!$%"& ' Figure 5: Success Ratio with Flooding 7 8 A 7 Z Y [ W X V V UT T R S 7 8? 7 8 > 7 8 = 7 8 < 7 8 ; 7 8 : \4]59 \4]: \4]6; \4]6= \4]> \4]597 \4]59= BCD 7 8 :BCD 7 8 ;BCD 7 8 <BCD 7 8 =BCD 9BCD 977BCD EF GHI JK!LEM N H!O%MJP Q Figure 6: Success Ratio with Closest-Unicast Figure 5 shows the success ratios for different and k for the top line in Figure 4. When 0.1 seconds, the success ratio drops rapidly as k increases. As increases, the success ratios with higher k values approach a stable value. From Figure 5, we can observe the appropriate time-out threshold would be 0.3 seconds. Similar trend can be observed from Figure 6 for Closest-Unicast. The success ratios of higher k values stabilize faster than in Figure 5. For example, the success ratios do not change very much after 0.2 seconds. This makes sense because the MOCAs are chosen based on the hop count in Closest-Unicast so the CREPs will arrive earlier from the close MOCAs. One thing easily noticeable from the two detailed looks at the success ratio is that the marginal safety value plays an important role in determining the success ratio within a given time-out threshold,. For example, the leftmost set of bars in Figure 5 represents the success ratio with time-out value set to 0.1 seconds. Each bar in the set represents the success ratio under varying values of k. For example, when k = 1, which is practically a replicated CA case, the success ratio within 0.1 seconds is almost 98%. In comparison, when k is set to 10, the success ratio within the same time-out threshold drops down to little 14

16 less than 70%. The same general trend can be observed over all the sets in Figure 5 and also with the unicast-based approach in Figure 6. These detailed graphs can be helpful when deciding an adequate time-out threshold for a given k. For example, if k is set to 15 out of 30 MOCAs for a network using Closest-Unicast, can be chosen to be 0.2 seconds to maintain higher than 90% success ratio. 4.5 Unicast Success Ratio As shown in the previous subsection, the choice of and given k has dominant effects on the success ratio. In this subsection, we present the detailed comparison of success ratios with varying and values, among the different unicast-based approaches. To clearly observe and compare the effectiveness of different unicast-approaches, we eliminate the effects of flooding from the graph and only present the success ratio among the unicast CREQs. Figures 7, 8, and 9 respectively show the success ratio of the Random-Unicast, Closest-Unicast, and Freshest-Unicast approaches with 15. Generally, all three approaches achieve 60 to 70% success ratio among the unicast CREQs. Success in this case is defined by the receipt of at least k CREPs for the unicast CREQs. When goes over 0.3 seconds, there is little improvement in all three graphs, which again suggests that 0.3 seconds can be used as an adequate time-out threshold value for this scenario /.., : 678 :!#"$$%'& )('%* + Figure 7: Unicast-only Success Ratio with Random-Unicast Closest-Unicast shows the best success ratio within 0.1 seconds time-out threshold, which makes sense in that the choice of MOCAs in Closest-Unicast is based on the smallest hop-counts. Thus, clients can expect to receive the fastest answers from MOCAs in this case. One interesting fact is, contrary to expectations, Freshest-Unicast does not perform better the Closest-Unicast. The intuition behind the Freshest- Unicast was that the most recently added or updated routes should have the least probability of being stale so that client should be able to expect the highest success ratio given enough time. More thorough investigation revealed that the reason was because that there is not much difference between the freshness of cached routes. At any point of time, the maximum difference between the expiration time of all cached routes in a node was less than 0.1 seconds. Considering the scale of expiration timer is around 10 seconds, 0.1 seconds difference is not large enough to distinguish the fresher routes. So, among the three different 15

17 1.. -,, ^ [[ ZYY 23 /0 * !"##$&% '&$() Figure 8: Unicast-only Success Ratio with Closest-Unicast _` \] WX ; 9 :C 9 :B 9 :A 9 :@ 9 :? 9 :> 9 := 9 :< 9 : ; 9 9: 9=DEFG9 : 9?DEF 9: ;DEF 9: ;H?DEFI9: <?DEF 9 :?DEF ;DEF JK LMN OPQ#J#R&S MTR OU V ; < ;9 ;? Figure 9: Unicast-only Success Ratio with Freshest-Unicast 16

18 unicast approaches we tested, Closest-Unicast turns out to be the most efficient and also the most effective. However, it would be interesting to investigate if Closest-Unicast still performs best with background data traffic. We discuss more about potential extension in the next section. 5 Future Work Our current -unicast approaches only exploits information in the local routing cache. One potential extension is to let a node browse into neighboring nodes routing tables. For example, a node may have one or two cached routes short of and has to fall back to flooding. If the node has a way to peek into the neighbors routing tables and find couple of new cached routes, it can avoid flooding and using -unicast. Potential overhead from this approach would be the extra communication required between neighbors to exchange the information in routing tables. Whether the benefit would surpass the overhead is an interesting question to investigate. All the unicast-based approaches in our current protocol do not take into account the direction of CREQs. For an extreme case, all the MOCAs picked by our unicast approach could reside on one side of the network from the requesting node. Then it is possible that all the CREQs are sent into one direction sharing the same next hop nodes, potentially causing unnecessary contention that leads to a failure or at least delayed responses. One possible solution for such situation is to utilize the next hop field in the cached routing table entries. For example, by selecting a set of MOCAs with all the different next hops, we can expect to have a spatial load balancing effect in that each CREQ will go out in different directions. As mentioned in a previous section, there are certain similarities between our certification protocol and on-demand ad hoc routing protocols, particularly in that both protocols use and maintain the routing tables in the intermediate nodes. By using our certification protocol with one of the ad hoc routing protocols simultaneously, both protocol may be able to benefit from each other by sharing the routing information. For example, our certification protocol may be able to discover more cached routes to MOCAs thanks to the ad hoc routing protocol and vice versa. There are many interesting and promising security services and applications that can be deployed in ad hoc networks using the support of PKI. For example, some secure ad hoc routing protocols that assume the existence of PKI support can readily utilize our framework. However, it is yet unclear how all these different security services and applications will fit with each other in broader aspects. We plan to study how our approach can be integrated with other security services or applications and what kind of effects that will generate. 6 Conclusion In this paper, we present a practical key management framework for ad hoc wireless networks. We clarify the necessity and the problem of providing a key management framework for ad hoc networks and identify the requirements for such framework. Based on our observation of potential heterogeneity among mobile nodes, we provide an intelligent way to pick a set of secure nodes. These selected secure nodes are called MOCAs and share the responsibility of collectively providing the CA functionality for an ad hoc network using threshold cryptography. To minimize the usage of scarce resources in mobile nodes, we develop a set of efficient and effective communication protocols for mobile nodes to correspond with MOCAs and receive certification services without prohibitive overhead. Our simulation results show the effectiveness of our approach and we provide some insights into the configuration of such security services in ad hoc networks. 17