Traditional key management service is based on a central authority (CA) or a trusted third party (TTP) to issue public key certificates to all nodes in the network. However, providing key management by relying on a single TTP or CA is not applicable within the pervasive environment of mobile ad hoc networks (MANETs). In the mobility environment of MANETs, only distributive key management schemes can work efficiently.

In this paper, a threshold key management protocol for MANETs using elliptic curve dlog-based cryptosystem is proposed. In the proposed scheme, an off-line authority is required in the network initialization phase before network deployment. The off-line authority constructs the shares matrix for each node in the network by distributing a large number of secrets to all network nodes according to a verifiable secret sharing (VSS) scheme 1, 2. After network deployment, the off-line authority has no role in the network. When a group of nodes wish to establish a secure session, a node from the session broadcasts a session formation request. The request includes the identities of the session members, the required threshold of the session, and a nonce. Each session member collaborates with its neighboring nodes to generate its private/public key pair, other session members public keys, and the session public key. Neighboring nodes provide session members with the required shares even if the neighboring nodes are not session members. The degree of the secret sharing polynomial used by the off-line authority to generate the shares matrix for each node determines the number of neighboring nodes needed to provide the required shares to session members. This paper extends our previous work in Reference 3 by introducing the shares matrices refreshing algorithm and the new member joining algorithm. In Reference 3, the performance of the session key generation (SKG) algorithm was evaluated with respect to the CA threshold () only, but in this paper we measure the computations and communications overheads of the proposed scheme with respect to both the CA threshold () and the group threshold ().

The rest of the paper is organized as follows: Section 2 reviews related works. Section 3 provides the scheme description of our proposed scheme. The security analysis of the proposed scheme is then presented in Section 4. The performance evaluation of the proposed scheme is presented in Section 5. Finally, Section 6 concludes the paper.

RELATED WORKS

In this section, a review of related key management schemes are presented. In Reference 4, we presented a robust self-organized public key management for MANETs. This scheme allows each user to create its public key and the corresponding private key, to issue certificates to neighboring nodes, and to perform public key authentication through at least two independent certificate chains without relying on any centralized authority. In Reference 5, Blom presented a SKG system based on the computation of a symmetric matrix which provides a key space for all users that possess a public and a private share of the key space. In Reference 6, and Reference 7, threshold cryptography has been proposed to provide a reliable, distributive key management for MANETs by exploiting some nodes as a trust anchor for the rest of the network. A model for distributing trusted services (by using threshold cryptography 8) among a set of servers despite some servers being under control of an attacker has been proposed by Cachin in Reference 9.

In Reference 2, a non-interactive VSS was presented by Feldman. The scheme is optimal in that it tolerates up to bad players, which is provably bitwise secure, assuming the intractability of taking discrete logarithms. This scheme also shows that the VSS can be used as a subroutine to simulate a simultaneous broadcast network, which makes protocols such as secret bidding as efficient as the best VSS.

In Reference 10, the first distributed key generation (DKG) scheme was proposed by Pedersen in 1991. The basic idea in Pedersen's DKG protocol 10 is to have parallel runs of Feldman's VSS protocol 2 in which each player acts as a dealer and selects a random secret . The secret value is the sum of the shared 's. The public value is taken to be the product of the 's that correspond to the shared 's since Feldman's VSS has the additional property of revealing . Chronopoulos et al. proposed a practical implementation of DKG on a network of computers in Reference 11. In this scheme, secure sockets are used to create the private channels over the Internet. A modified version of Pedersen's DKG protocol 10 has been proposed in Reference 12. The modified DKG protocol 12 is proved to satisfy the security requirements from DKG protocols and, in particular, it ensures a uniform distribution of the generated keys. The modified DKG tolerates up to halting players for and eavesdropping players for and static adversary for . The protocol can be used as a secure replacement for the many applications of Pedersen's protocol.

In Reference 13, an elliptic curve distributed key generation protocol has been proposed by Tang et al. In this protocol, a player can reveal its public key share only when all other players in their local non-disqualified sets have agreed not to change their local non-disqualified sets. A nonce is used as a timestamp to emulate the timeout and serves as a confirmation to other players that this player is ready to extract its public key. However, this scheme suffers from the heavy communication overhead required to perform the protocol successfully. In Reference 14, Huaqun Wang and Jiang proposed a key management scheme based on the homomorphism of elliptic curve Paillier scheme. This scheme addresses only the new node joining process. In addition, the generation of the new node's sub-key is performed in a serial manner among the new node's honest neighbors. Hence, the authentication process of the new node is time consuming. In Reference 15, Liu et al. proposed a key management and authentication model for ad hoc network. This scheme is based on the combination between elliptic curve and ID-based cryptography. This scheme is vulnerable to the man-in-the-middle attack.

SCHEME DESCRIPTION

The notations used in the proposed scheme are shown in Table I. The network initialization phase and network deployment phase of our proposed scheme are shown in Figures 1 and 2, respectively. In the proposed scheme, a CA is required in the initialization phase only as shown in Figure 1. CA selects an appropriate elliptic curve and determines the elliptic curve cryptography domain parameters. We make the following assumptions in the proposed scheme:

Each user in the network has a unique identification number in where is a prime or .

Each node is assumed to have a long term public/private key pair , where the public key is known to all mobile nodes in the network (where is the point multiplication by a scalar operation).

The proposed key management scheme works in support of an ad hoc on demand routing protocol (such as ad hoc on-demand distance vector (AODV) 14)

The maximum number of nodes that can be compromised in the network is nodes.

The computation power capabilities of mobile nodes are sufficient to perform the required computations for the proposed scheme.

Table I. Notation.

G

Base point of elliptic curve selected by the CA

One way hash function

Number of secrets chosen by the CA

Share of the secret given to node

Threshold number of nodes required to provide shares

Threshold number of nodes required to form a session

Number of nodes in the network

W

Group of session members

Secret share generated by node node

Public share generated by node node

Elliptic curve point multiplication by a scalar

Point summation under point add operation

Signature of node

Private key of node generated in the session

Public key of node generated in the session

Session public key

Elliptic curve cryptography domain parameters

The operation of any cryptographic scheme involves arithmetic operations on an elliptic curve over a finite field determined by some elliptic curve domain parameters. If is an elliptic curve over a finite field , then let denote the points in including the point at infinity . The parameters of the elliptic curve are as follows: , where is a prime power , an indication of the method used for representing field elements, and are the coefficients of the elliptic curve equation. is the base point of the elliptic curve , denoted as , a prime which is the order of , and finally the cofactor (), where denote the number of points on elliptic curve .

Shares matrices generation

An overview of the shares matrices generation process is shown in Figure 3.

Let be the set of nodes in the network initialization phase, where

The set of nodes has a cardinality equal to and nodes that are identified by their unique identities , where . Shares matrices generation phase includes the following steps:

Step 1. CA selects secret keys , where

Step 2. CA rearranges the selected secret keys from the previous step and constructs the following secret keys matrix:

(1)

where .

Step 3. CA picks secret polynomials , such that:

(2)

where , .

Step 4. Using the secret polynomials from the previous step, the CA computes secret polynomial shares for each node such that: , where , , and .

Step 5. CA establishes, and preloads the following shares matrix to node before network deployment:

(3)

Shares of the same indices in the shares matrices of every mobile node represent shares for the same secret . Any group of nodes can collaborate to generate a CA secret such that:

(4)

where , .

The parameter chosen by the CA determines the number of neighboring nodes needed to collaborate with a session member in order to construct its private/public key pairs, session members public keys, and the session public key. This parameter cannot be changed after the system is set up.

Session key generation

An overview of the SKG process is shown in Figure 4.

When a group of nodes wish to generate session keys to be used in securing communications for this session (for example generate a signature for a message ), they follow the following steps:

Step 1. The mobile node which has the largest identity number over all other session members (for example node 22 in Figure 2) broadcasts a session formation request as follows:

where is a large random number that can be used only once for each session (it is used as a refreshness mechanism to randomize the session keys generation process and to prevent the replay attacks), is the number of shares to be picked from the shares matrix by each node in order to construct its secret sharing polynomial, are the identities of the session members, TTP is the life time of this session formation request, and is the digital signature of the mobile node using its long term private key .

Step 2. When a neighboring node (which is not necessarily a session member and not limited to the one-hop neighbors) receives the request, it authenticates the origin of the request by verifying the signature of the sender node using the mobile node 's long term public key .

Step 3. When the verification succeeds, mobile node maps the session member and the Nonce by using a recursive hash functions , where , to obtain shares indices to be picked from its shares matrix as follows:

(a)Calculate row numbers as follows:

(5)

where

(b)Calculate column numbers as follows:

(6)

where

Step 4. Mobile node picks shares from its shares matrix (refer to Equation (3)) according to the rows and columns indices obtained from the previous step such that , and constructs its secret sharing polynomial as follows:

(7)

such that, for

$$a_{i}^{(j)} = s_{R_{i} C_{i} }^{(j)} $$. (8)

Step 5. Using its secret sharing polynomial, node calculates a share for each session member as follows:

(9)

where .

Step 6. Node calculates the public shares , where

(10)

and sends out the following reply to the session member node :

where refers to the encryption of the share using the public key of node .

Step 7. Mobile node computes and broadcasts the following public values:

Step 8. Mobile node collects at least replies from its neighboring nodes in addition to its own calculations from the previous steps to reconstruct its private/public key pair, session members public keys, and the session public key as follows:

(a)The private key of the mobile node in this session is calculated as follows:

(12)

(b)The public key of the mobile node in this session is

(13)

(c)The session member calculates the public key for other session members , where as follows:

(14)

(d)The session member calculates the session public key by Lagrange interpolation of public keys of at least session members as follows:

(15)

where is the threshold number included in the session formation request which determines the minimum number of mobile nodes required to form the session.

The advantage of the key generation method described above is that shares matrices of quite small sizes can form a very large key space. If the size of the shares matrix is m × d, and the threshold is , then the key space will be equal to

(16)

We now explain the SKG process with the help of the example in Figure 5. We assume the values of (threshold number of nodes required to recover a shared secret) and (threshold number of nodes required to form a session) are both equal to 3 in this example. Let nodes 2, 7, 15, and 22 wish to establish session keys to be used in securing communications inside the group. Node 22 which has the largest index among all other session members, broadcasts the following session formation request (refer to step 1 in subsection 3.3):

For simplicity let Nonce equal to 451 and the size of the shares matrix of each node is . When receiving the request, neighboring nodes of the session members calculate the indices of the shares to be picked from their shares matrices as follows:

(1)Using Equation (5), calculate rows indices as follows:

(2)Using Equation (6), calculate column indices as follows:

(3)According to the indices calculation, node which is a neighbor of a session member picks the corresponding shares from its shares matrix as follows: , , and .

(4)Each neighbor builds its secret sharing polynomial using the shares he picked in the previous step as follows: . For example, taking Equation (3) into consideration, refers to the share with row number equal to 5 and column number equal to 7 in the shares matrix of node .

(5)Each neighbor calculates a share for each session member as shown in Table II and completes steps 6, 7, and 8 in the SKG process.

Table II. Calculated shares by neighbors of a session member.

Session member

Calculated shares

Node 2

Node 7

Node 15

Node 22

Shares verification

There are two verification methods a session member can perform to prevent malicious nodes from inserting faked shares during the computations of the session keys. The first verification method can be performed as follows:

Step 1. Each session member (where ) verifies the shares it received from its neighboring nodes. Node checks if

If the verification fails, broadcasts a complaint against .

Step 2. Each mobile node that received a complaint from another mobile node broadcasts the values that satisfy Equation (17).

Step 3. Mobile node deletes the shares it received from the mobile node if it received more than complaints against in step 1, or if the reply of the mobile node in step 2 does not satisfy Equation (17).

Step 4. Each session member verifies its session secret key share it received from another node by checking if

(18)

If the verification fails, broadcasts a complaint against and repeat step 2 and step 3.

The second verification method can be performed as follows: as the session member node collects at least replies from its neighboring nodes, it then tries the different combinations of using out of the received shares in addition to its own calculation in steps 2–6 in subsection 3.3 when calculating the session keys. If all the combinations are identical, then there is no malicious node among the replies senders. Otherwise, if there is a combination that results in different session keys, the excluded shares from this combination is considered faked and broadcasts a complain against the mobile node where the faked shares were sent from. This method is useful only if there is no more than one malicious node among the senders of the replies as it can detect one fake reply only.

Shares matrix refreshing

Each mobile node protects its shares matrix from being compromised by storing it in an encrypted format in a tamper-resistant storage. However, there is still some risk that a mobile node is compromised and its shares matrix revealed. During the network life time, an adversary may compromise mobile nodes, hence disclosing the system secrets. In order to prevent these types of attacks, a periodical share refreshing scheme should be performed without changing the system secrets. The share refreshing scheme is based on the following property: when a secret is distributed to nodes by using the polynomial

(19)

where such that are shares of the secret , and another secret is distributed to nodes by using the polynomial

(20)

where such that are shares of the secret then according to the linearity property, are shares of the secret by using the polynomial , where . The aim of our share refreshing scheme is to meet the following:

Share refreshing process does not reveal any additional information than the key generation process.

The key management scheme should be available for usage during the share refreshing process.

An overview of the shares refreshing process is shown in Figure 6.

For simplicity, the share refreshing process for one element () in the shares matrix of each node can be described as follows:

Step 1. Each mobile node , chooses a random polynomial of degree as follows:

(21)

where , and .

Step 2. computes , and sends the following message to :

Step 3. computes and broadcasts the following public values:

(22)

where ().

Step 4. Each node in the network decrypts the received message from node in step 2 and verifies the share it received as follows:

(23)

If the verification fails, broadcasts a complain against .

Step 5. Each node that received a complaint from another node broadcasts the value that satisfies Equation (23).

Step 6. Node removes node from its trusted group if it received more that complaints against in step 4, or if the reply of the node in step 5 does not satisfy Equation (23).

Step 7. Node computes the new share in its shares matrix as follows:

(24)

Network nodes repeat these steps to complete the shares refreshing process for all elements in their shares matrices.

SECURITY ANALYSIS

The proposed threshold key management scheme achieves the correctness and secrecy requirements necessary to provide a distributed key generation protocol based on ECDLP as mentioned in References 12, 13. In this section, a security analysis of the proposed scheme in the initialization phase, and in the network deployment phase, is presented.

Initialization phase

Correctness

The CA secret shares (where ) are uniformly distributed in , and the generated shares matrices are uniformly distributed in . Any subset shares with the same matrix indices from any honest mobile nodes define the same secret .

Secrecy

No subset of less than mobile nodes can recover a CA secret . In order to increase the secrecy of the preloaded shares matrices, each matrix element is generated from a different secret polynomial chosen by the CA. The Nonce is used in the session formation request to randomize the process of session keys generation. Therefore, if the same session members wish to generate another session after the expiration of the previous one, the indices of the shares matrices elements (refer to Equations (5) and (6)) required to construct the secret sharing polynomial for each replying node will be different from the previous session which results in completely different session keys.

Network deployment phase

Correctness

The private session key of each session member is uniformly distributed in , and the corresponding public key is uniformly distributed in since the determination of whether the neighboring nodes participating in the session keys generation process are honest or not depends on public broadcast information as in step in subsection 3.3.

Theorem 1. All subset secret sharesprovided by any honestneighboring nodes() define the same secret keyfor mobile node() if theneighboring nodes picked shares with the same indices () from their shares matrices, where ().

Proof. Without loss of generality, by rearranging Equation (12), a group of neighboring nodes provides shares to the node to generate its private key of node such that:

If all the nodes picked the shares corresponding to the same indices () from their shares matrices (which are shares for the same secret as shown in subsection 3.2) then by substituting Equation (4) in Equation (28) we get

(29)

which can be constructed from the replies of any group of nodes if they picked shares with the same indices from their shares matrices.

Theorem 2. All subset public sharesprovided by any honestneighboring nodes() define the same public keyfor mobile node() if theneighboring nodes picked shares with the same indices () from their shares matrices, where ().

Proof. By rearranging Equation (12), from the replies of any group of neighboring nodes, the mobile node can generate its public key such that:

With all the nodes picking the shares corresponding to the same indices from their shares matrices (), and by substituting Equation (4) in Equation (34) we get:

(35)

(36)

which can be constructed from the replies of any group of nodes if they picked shares with the same indices from their shares matrices.

Theorem 3. Each session membergenerates the same session public keyfrom the replies it received from any group ofneighboring nodes (refer to Equation (15)) if they picked shares with the same indices () from their shares matrices, where ().

Proof. Taking Equation (15) into consideration, this theorem is a direct result of theorem 2.

Secrecy

In this subsection, we analyze the impersonation attack and the replay attack of the proposed key management scheme.

Impersonation attack

Theorem 4. It is computationally infeasible for an adversary to impersonate a legitimate node.

Proof. When an adversary wishes to perform impersonation attack to a mobile node (for example, to send a session formation request), he needs to forge the digital signature of the mobile node . We assume that forging the digital signature of the mobile node without obtaining its long term private key is computationally infeasible in our model.

Replay attack

The replay attack occurs when an adversary can intercept the routing and data packets and resend them. We focus on the replay attack that can be performed by an adversary to resend a session formation request (refer to step 1 in subsection 3.3).

Theorem 5. It is computationally infeasible for an adversary to successfully replay an honest node's session formation request.

Proof. According to step 1 in subsection 3.3, each session formation request includes a which acts as a unique one-time session ID to prevent an adversary from replaying the session formation request. In addition, the session formation request is a public information that can be intercepted by any node in the network and can be authenticated by verifying the digital signature of the sending node. When a node receives a duplicated session formation request during the life time (TTP) of the original session formation request (i.e., it has the same , the same session members IDs, and the same TTP), it ignores the duplicated session formation request. If an adversary succeeded in running a replay attack to broadcast session formation requests, It will add computations and communication overheads to nodes decided to participate in the SKG process. However, running the replay attack does not reveal any additional information about the shares matrix of the participating nodes because the replies to the session formation requests are encrypted using the recipients long term public keys and can be decrypted only by using the recipients long term private keys (refer to step 6 in subsection 3.3).

PERFORMANCE EVALUATION

In this section, the performance evaluation of our proposed threshold key management scheme is presented. We measure the computation complexity and communication overhead of our proposed scheme in comparison of that of Gennaro et al.'s Scheme 12. These comparisons highlights the performance improvement achieved in our proposed scheme compared to the performance of Gennaro et al.'s Scheme 12.

Computation overhead

We measure the computation overhead of the proposed scheme by presenting its timing results in comparison with that of Gennaro et al.'s Scheme 12. The execution time (speed) of the key management scheme reflects its computation overhead. The point multiplication by a scalar operation is the most time consuming operation in elliptic curve cryptography and hence it dominates the computation time of the scheme.

An overview of Gennaro et al.'s scheme

Step 1. Each mobile node chooses two random polynomials , of degree as follows:

(37)

(38)

where , , and .

Let is the private key of the server node .

Step 2. Compute the shares , for and sends , to using the private channel.

Step 3. Compute and broadcast the following public values:

(39)

where , is the base point, and is another point the discrete logarithm of which with respect to is not known.

Step 4. Each server node verifies the shares it received from other server nodes. checks the following verification for :

(40)

If the verification fails, broadcasts a complaint against .

Step 5. Each server node that received a complaint from another server node broadcasts the values , that satisfy Equation (40).

Step 6. Server node removes server node from its trusted group if it received more that complaints against in step 4, or if the reply of the server node in step 5 does not satisfy Equation (40).

Step 7. Each server node computes its public key and broadcasts .

Step 8. Each server node receives and computes the session public key

(41)

Discussion

In this section, we highlight the main differences between our proposed scheme and Gennaro et al.'s scheme which have major impacts on the communications and computations overheads of both schemes. In our proposed scheme, the computations in the SKG process depends mainly on the parameters and which can be adjusted to . In Gennaro et al.'s scheme, the computations in the SKG process depends mainly on . In our proposed scheme, each session member needs to communicate and obtain shares from any neighbors (refer to step 8 in subsection 3.3). While in Gennaro et al.'s scheme, each session member has to communicate and obtain shares from all other session members (refer to step 2 of Gennaro et al.'s scheme) which can be hard to achieve in the mobility environment of MANETs.

Timing results

We measure the computation overhead of our proposed scheme by calculating the time consumed in each process (SKG, Shares Matrix Refreshing, and New Member Joining). The computation timing reflects the computation overhead of the proposed scheme such that the higher the computation overhead, the higher the computation timing. The fundamental operation underlying elliptic curve cryptography (ECC) is point multiplication, which is defined over finite field operations. The point multiplication operation is the most complex operation in any elliptic curve based cryptosystem and the higher the number of point multiplication operations, the higher the required computation timing. Elliptic curves are defined over either prime fields or binary fields . In environments in which an arithmetic processor is already available, the performance of can be improved so that in some cases it exceeds the performance of . In the performance evaluation of our proposed scheme, we consider only prime fields since binary field arithmetic, is insufficiently supported in PARI/GP 16 and would, thus, lead to lower performance. On a desktop PC with an Intel Core 2 Duo 2.6 GHz processor and 1 GB memory, PARI/GP 16 is used to evaluate the performance of our proposed scheme. The prime elliptic curve over is defined by the equation

(42)

where and for is a prime and satisfy

(43)

The domain parameters (refer to subsection 3.1) used in our implementation are as follows.

A field size which defines the underlying finite field , where is a prime number; two field elements and in which define the equation of the elliptic curve ; two field elements and in , which define a point of prime order on ; the order of the point (it must be the case that ; and the cofactor (number of points on elliptic curve/p). The performance evaluation of the proposed scheme will be given in terms of the two thresholds and (out of the total mobile nodes). The performance of the proposed scheme is evaluated for three different key sizes: 192, 239, and 256 bits 17. The total number of mobile nodes in the network is set to 30 nodes. Values that remain constant between different scheme runs (for example, the inner parts of the Lagrange coefficients) can be precomputed and are, therefore, not included in the evaluation.

Session key generation (SKG) timing

Figures 7–9 show the SKG timing of our proposed scheme compared with that of Gennaro et al.'s Scheme 12 for key sizes 192, 239, and 256 bits, respectively. The SKG timing is illustrated with respect to the CA threshold and the group threshold . The SKG timing presented in these figures are the total time of both the generation and verification processes described in subsections 3.3 and 3.4, respectively. For a group threshold equal to 5, the SKG timing of our proposed scheme is 70–80 per cent less than that of Gennaro et al.'s scheme for the same values of . For equal to 10, the SKG timing of the proposed scheme is 60–70 per cent less than that of Gennaro et al.'s scheme for the same values of . For equal to 20, the SKG timing of the proposed scheme is 30–40 per cent less than that of Gennaro et al.'s scheme.

When approaches (the total number of nodes), the SKG timing of our proposed scheme approaches that of Gennaro et al.'s scheme. A comparison of the SKG timing of our proposed scheme to that of Gennaro et al.'s scheme is summarized in Table III. The gain in the computation overhead of our proposed scheme compared to Gennaro et al.'s scheme comes from the fact that the computation in Gennaro et al.'s scheme depends mainly on the total number of nodes in the session and the threshold while in our proposed scheme, the major part of the computation (session members private/public key pairs and session public key) depends on the parameters and which can be adjusted accordingly. When equal to for the same value of , the timing results of our proposed scheme approaches that of Gennaro et al.'s scheme because at this point each session member needs to obtain shares from all nodes in the session (which is the same case as in Gennaro et al.'s scheme). The SKG time increases with increasing threshold as a result of increasing the point multiplication operations in the computation of the session public key as shown in Equation (15). Increasing the key length from 192 to 239 bits and to 256 has a minor effect on the timing of the SKG process.

Table III. SKG timing comparison.

Group threshold ()

CA threshold ()

Proposed scheme compared to Gennaro et al.'s scheme

5

5–30

80–70 per cent less

10

5–30

70–60 per cent less

20

5–30

40–30 per cent less

30

5–30

Equal timing

Shares matrix refreshing timing

Taking into consideration the example of the shares matrix memory size of 12 kbytes presented in subsection 3.3 (which can be of a dimension ).

Table IV shows the share refreshing generation and verification time of our proposed scheme for a shares matrix of dimension for different CA threshold (). From Table IV, we conclude that the share refreshing process is computationally expensive compared to the SKG process. This results from the fact that all network nodes are involved in the computations of updating shares of a large number of secrets ( secrets in this case) in addition to the heavy computations of verifying each updated share. Table V presents the share refreshing timing of Gennaro et al.'s scheme for different CA threshold (). The share refreshing process in Gennaro et al.'s scheme is much less computationally expensive than our proposed scheme. However, in Gennaro et al.'s scheme, the share refreshing process updates only one session key, but the share refreshing process in our proposed scheme updates shares that can produce a key space of possible keys. If all elements of the shares matrix are updated at each share refreshing process, the computation overhead will be expensive as shown in Table IV. Thus, in our proposed scheme, we suggest that mobile nodes update only one column of their shares matrices in each share refreshing process. The timing results of updating one column of the shares matrix (16 elements) are shown in Table VI.

Table IV. Proposed scheme share refreshing timing in ms.

CA threshold ()

192-bits Curve

239-bits Curve

256-bits Curve

Generation

Verification

Generation

Verification

Generation

Verification

5

4642

37380

7672

60879

8586

67912

10

10483

40836

17225

65311

19358

72664

20

22223

47563

36408

74009

47249

81582

30

34586

54971

55540

82717

62206

90633

Table V. Gennaro et al.'s scheme share refreshing timing in ms.

CA threshold ()

192-bits Curve

239-bits Curve

256-bits Curve

Generation

Verification

Generation

Verification

Generation

Verification

5

15

115

25

184

28

203

10

30.90

178.71

49.90

269.20

56.03

292.08

20

59.86

418.48

99.77

594.92

112.02

630.31

30

89.94

811.72

149.68

1129

168.58

1186

Table VI. Proposed scheme share refreshing timing for one column in ms.

CA threshold ()

192-bits Curve

239-bits Curve

256-bits Curve

Generation

Verification

Generation

Verification

Generation

Verification

5

193

1558

320

2537

358

2829

10

437

1701

718

2721

807

3028

20

926

1982

1517

3084

1969

3399

30

1441

2290

2314

3447

2592

3776

Communication overhead

Radio communications are the most energy consuming operations in wireless networks. In this subsection, we evaluate the communication overheads of the proposed scheme in two methods. In the first method, we evaluate the number of messages involved in each algorithm of the proposed scheme. In the second method, network simulations of the proposed scheme in realistic scenarios are performed using Network Simulator (NS-2) 18.

Messages evaluation

Table VII summarizes the communication overheads of the proposed scheme by presenting the number of unicast and broadcast messages in each algorithm.

Table VII. Communications overhead.

Algorithm

Transmission

Reception

Broadcast

Unicast

SKG

0

SKG verification

0

Share refreshing

0

Share refreshing verification

0

New member joining

0

New member joining verification

2

0

Network simulation

The MAC layer protocol IEEE 802.11 is used in all simulations. The source–destination pairs are spread randomly over the network. The NS-2 constant bit-rate (CBR) traffic generator is used to set up the connection patterns with different random seeds. The simulation results are the average of 10 runs. Every simulation run is 1000 s long with random network deployment and random mobility patterns. The mobgenss 19 mobility scenario generator was used to produce random mobility patterns. The pause time is set to zero. The total number of mobile nodes in the simulation is set to 50, while the number of mobile nodes which are trusted by the CA and have shares matrices is set to 30 out of the total 50 mobile nodes. The AODV routing protocol 20 was chosen for the simulations. The share reply packet size is set to 512 bytes. The rest of the simulation parameters are summarized in Table VIII.

Table VIII. Simulation parameters.

Parameter

Value

No. of nodes

50

No. of SKG nodes

30

Area (m^{2})

1000 × 1000

Transmission range

250m

Mobility Model

Random waypoint

Propagation Model

Two-ray ground

Mean speeds (m/s)

0.1, 5, 20

Data rate

11 Mbps

Load

4 packet/s

Share reply packet size

512 bytes

Performance Metrics: We have selected the Session Key Generation Success Ratio as a metric to evaluate the performance of the proposed scheme.

Session key generation success ratio

It is the ratio of the number of completed SKG process to the number of session formation requests sent (refer to step 1 in subsection 3.3).

Simulation Results: The communication overhead of our proposed scheme is measured for node mobility 0.1, 5, and 20 m/s.

Figure 10 shows the SKG success ratio with respect to the group threshold and the CA threshold in comparison with that of Gennaro et al.'s scheme for mobility 0.1 m/s. It shows that the SKG success ratio varies from 98 to 35 per cent by increasing the CA threshold from 5 to 30 but on the other hand the effect of the group threshold on the SKG success ratio is negligible. The SKG success ratio in Gennaro et al.'s scheme does not exceed 35 per cent for node mobility 0.1 m/s.

Figure 11 shows that the SKG success ratio of our proposed scheme for node mobility 5 m/s decreases from 96 to 21 per cent by increasing the CA threshold from 5 to 30. In Gennaro et al.'s scheme, the SKG success ratio for node mobility 5 m/s is 21 per cent.

Figure 12 shows that the SKG success ratio decreases from 96 to 12 per cent with increasing the CA threshold from 5 to 30 for node mobility 20 m/s. The SKG success ratio in Gennaro et al.'s scheme for node mobility 20 m/s is 12 per cent. Increasing the CA threshold in Figures 10–12 results in decreasing the SKG success ratio. This is due to the fact that increasing the CA threshold increases the number of nodes a session member needs to successfully communicate with in order to get their shares contributions in the SKG process (refer to step 8 in subsection 3.3). On the other hand the effect of the group threshold on the SKG success ratio is negligible because increasing the group threshold has no effect on the number of nodes needed to provide their shares to a session member in the SKG process. The SKG success ratio of our proposed scheme exceeds that of Gennaro et al.'s scheme because in our proposed scheme, each session member needs to obtain shares from only neighboring nodes while in Gennaro et al.'s scheme, each session member needs to obtain shares from all other session members which is often hard to achieve in the mobility environment of MANETs. A comparison of the SKG success ratio for different node mobility is summarized in Table IX. Table X summarizes the standard deviation between the 10 results of the SKG success ratio runs. It shows the standard deviation of the SKG success ratio with respect to the CA threshold () for different node mobility 0.1, 5 and 20 m/s.

Table IX. A comparison of session key generation success ratio.

CA threshold ()

SKG success ratio

0.1 m/s mobility (per cent)

5 m/s mobility (per cent)

20 m/s mobility (per cent)

5

98

96

96

10

92–97

90–96

90–94

20

60–80

44–73

42–66

30

35

21

12

Table X. Standard deviation between SKG success ratio runs.

Threshold ()

0.1 m/s mobility

5 m/s mobility

20 m/s mobility

5

6.32–22.4

9.66–23.24

6.32–20.11

10

6.75–26.16

4.22–13.54

6.75–15.33

20

5.16–13.22

3.94–18.1

4.97–16.12

30

5.46–7.82

4.73–18.91

3.06–14.51

The value of CA threshold () is an optimization between the required security level and the QoS requirement. A very high CA threshold () provides greater security, but degrades the QoS. If the CA threshold () is lowered, it will be easy for session members to construct the session keys withing the QoS requirements, but the security of the network may be compromised. There are many parameters that can affect the selection of the CA threshold () such as the network density, node speed and threshold requirement. We have investigated the effect of changing the CA threshold (t) for different node speed on the SKG success ratio in Figures 10–12. In order to minimize the effect of changing the network density on the selection of the CA threshold () in our scheme, session members can obtain the shares required to construct the session keys from their higher-hop neighbors if the number of their one-hop neighbors is less than the CA threshold ().

Memory requirement

The size of the shares matrix stored in each node determines the key space available for the SKG process. For example, if each element in the shares matrix is 256 bits, then a shares matrix of 12 kbytes size (which is small enough to be stored in a mobile ad hoc node with limited memory size) with the threshold equal to 5 can produce session keys. In addition to the memory required by each node to store its shares matrix, each node needs to store the identities of all network nodes which is equal to bits. The identity of each player is the permutation of bit long, where is the integer ceiling function, is the key length, and n is the number of nodes in the network. Each node in the network needs also to store the long term public key of all other nodes in the network (where ). The long term public keys of the network nodes can take a memory space equal to where is the length in bits of each single long term public key.

CONCLUSIONS

In this paper, a threshold key management scheme using elliptic curve dlog-based cryptosystem has been proposed. The proposed scheme does not require any prior communications between session members before forming the session. In the network deployment phase, nodes are free to select the group threshold , which is a major advantage of our scheme that enables mobile nodes to adjust the level of secrecy they require. From the timing results, our proposed scheme has very low timings compared to Gennaro et al.'s Scheme 12 as shown in Tables III, VI. Results also show that computations timing in our proposed scheme does not vary significantly with changing the key size which reflects the suitability of the proposed scheme for applications where devices are resource constrained such as in the mobile ad hoc environments. Our proposed scheme has a very low communication overhead compared to that of Gennaro et al.'s scheme. As a result, the SKG success ratio of our proposed scheme exceeds that of Gennaro et al.'s scheme for different node mobility when the number of CA threshold is less than the number of SKG nodes in the network as shown in Table IX. When the number of CA threshold is equal to the number of SKG nodes in the network (30 nodes in Table IX), the SKG success ratio of our proposed scheme approaches that of Gennaro et a.'s scheme.