Evaluation of Secure Multi-Hop Node Authentication and Key Establishment Mechanisms for Wireless Sensor Networks

Abstract

Designing secure authentication mechanisms in wireless sensor networks in order to associate a node to a secure network is not an easy task due to the limitations of this type of networks. In this paper, we propose different multi-hop node authentication protocols for wireless sensor networks. For each protocol, we provide a formal proof to verify the security of our proposals using Scyther, which is an automatic cryptographic protocols verification tool. We also provide implementation results in terms of execution time consumption obtained by real measurements on TelosB motes. These protocols offer different security mechanisms depending on the design of the protocol itself. Moreover, we evaluate the overhead of protection of each solution by studying the effect on execution time overhead of each protocol. Finally, we propose a mechanism to detect possible attack based on our evaluation results.

1. Introduction

Wireless sensor networks (WSNs) are increasingly used in critical applications where the identity of each communicating entity should be authenticated before exchanging data in the network. The wireless nature of this technology makes it easy for intruders to try to intervene in the network activity and create any of the known attacks in WSNs [1]. Many of the current propositions focus on message authentication for ensuring data authentication and integrity, and others focus on user authentication to give access to the network for certain user profiles. In this paper we propose, on one hand, authentication protocols that allow nodes to join the network in a secure manner, and on the other hand, key establishment protocols that allow nodes to establish keys with nodes that are multiple hops away.

Designing secure protocols is an error-prone task. One of the well-known examples is the famous flaw found in the Needham–Schroeder protocol seventeen years after its publication [2]. This protocol aims at establishing a new key between two participants. It is simple since it uses only three exchanges of messages. It clearly shows that designing secure protocols is not an easy task and is error-prone. During the past decades, several automatic tools for verifying the security of cryptographic protocols have been elaborated by several authors, e.g., Proverif [3], Avispa [4] or Scyther [5]. These symbolic tools use the Dolev–Yao intruder model [6], which considers that the intruder is controlling the network and makes the perfect encryption hypothesis (meaning that it is impossible to obtain the plain text of an encrypted message unless the secret key is known). The state-of-the-art [7] shows that formal methods are now mature and efficient enough to be used in the design of security protocol in order to avoid such logical flaws.

Another aspect that should be taken into account during WSNs protocol analysis is the performance related to the security operations. Traditional approach assumes that the best way is to apply the strongest possible security measures to make the system as secure as possible. Unfortunately, such reasoning leads to the overestimation of security measures, which causes an unreasonable increase in the system load [8]. The system performance is especially critical in systems with limited resources such as wireless sensor networks or mobile devices. It is important to design secure mechanisms using, when possible, a fixed number of cryptographic operations regardless of the network size, and to be able to evaluate their performance in such constrained devices. In this paper, we propose several protocols that do not add cryptographic operations on intermediate nodes. We systematically evaluate their overhead and prove their correctness with the automatic formal security verification tool Scyther [5].

The originality of our work resides in the fact that it suites large scale multi-hop wireless sensor networks, which is due to the limited number of cryptographic operations regardless of the number of hops separating the communicating nodes. In addition, it combines several aspects of security, from designing secure protocols to evaluating the implementation of our solution, going through formal automatic analysis of security and overhead of protection analysis. Our contributions can be summarized in the five following points:

• Design of multi-hop node authentication mechanisms.
• Formal automatic analysis of our solutions.
• Implementation on TelosB motes.
• Evaluation of the overhead of protection of our solutions.
• Attack detection based on the a priori overhead evaluation.

Our main contribution is the design of several secure authentication protocols. In order to avoid security flaws, we prove the correctness of all our protocols automatically using Scyther [9], which is a tool for the automatic verification of security protocols. This tool considers neither the cost of the communications nor the execution time of the cryptographic operations. Therefore we have implemented our protocols on TelosB motes in order to obtain the execution time and communication. Note that we used TelosB motes as a means for comparing the different protocols. We would have obtained better overall performance if we used motes with more computation capacities such as Tmotesky.The overhead of protection analysis for WSN cryptographic protocols is almost impossible to perform manually. This increases the difficulty to design secure and efficient protocols at the same time. Using our real implementation on TelosB motes, we have measured the execution time of every cryptographic operation and every step in each protocol. These measurements were obtained from a testbed of the minimal number of nodes. In addition, using the overhead evaluation results, we were able to put in place an attack detection process.

This paper does not aim to show that the proposed protocols are faster than existing protocols. Instead, the main objective is to present secure solutions for node authentication and key establishment using standard cryptographic algorithms and primitives available on the Internet. The chosen primitives can be replaced by more optimized primitives for better performance. The evaluation we presented is essentially a proof of concept and shows that the steps of each protocol can be implemented on low cost motes such as TelosB motes that are known for their low capacities in computation speed.

This work is an extension of the conference paper [10] and the book chapter [11]. The original authenticated join protocol was proposed in [11] and evaluated in different versions according to the level of protection in [10]. It is the only intersection with the current paper.

In the next section, we summarize the related work. In Section 3, we present the cryptographic primitives we use to design our protocols. Then in Section 4, we propose two protocols for establishing secure multi-hop communications. In Section 5, we give two key establishment protocols that use the sink as a trusted third party and in Section 6 we propose four protocols that establish a new key without passing by the sink. Then in Section 8, we use Scyther to formally prove the security of our solutions. In Section 9, we evaluate the overhead of our eight protocols. Based on the overhead evaluation results, we explain in Section 10 how a node is able to detect attack attempts launched by other nodes in the network. We conclude the paper in the last section.

2. Related Work

Very few works have been done for node authentication protocols in multi-hop WSNs. Most of the existing authentication protocols proposed for WSNs neglect the multi-hop factor. In [12], Al-mahmud et al. propose a protocol where the base station broadcast authentication elements for in-range sensor nodes to be able to authenticate new arriving nodes. In fact, they consider that any previously authenticated node can authenticate new nodes using identity-based signature (IBS) algorithm, Elliptic Curve Cryptography (ECC) and a digital signature algorithm (DSA). They provide an informal security analysis and have not implemented their protocols.

In [13,14], the authors propose an authentication mechanism for users and consider that sensor nodes inside the WSN are trusted nodes. In [14], Yeh et al. show the weakness of some protocols proposed in [13], due to lack of authentication. Then they propose a stronger authentication protocol using ECC that ensures mutual authentication and protection against attacks from other users, which was not included in [13]. They also provide a manual security analysis of their solution and only a theoretical complexity evaluation of their protocols.

Recently in [15], Han et al. propose an authentication model that aims at reducing overhead for the re-authentication of sensor nodes using symmetric and public key cryptography. It is based on a ticket encrypted using a common secret key between neighbouring fixed nodes. This ticket is sent to a mobile node during the first authentication phase. This ticket is only useful when the mobile node decides to re-authenticate with this neighbour fixed node. In addition, the protocol only works well when the fixed node is in direct range with the base station, and the initial authentication phase suffers from internal attacks. Sinks in the network can easily take the place of each other when they are not in communication range with the base station. The authors only give a quick informal security analysis of their solutions and they have not deployed their solutions on real motes.

In [16], Manjusha et al. propose an authentication technique using ECC and ElGamal digital signature scheme for message authentication. The authors do not perform any security analysis of their solution. Moreover, the proposition is evaluated on a computer using MATLAB simulator, which makes it difficult to estimate compared with a real testbed implementation, since digital signatures and public key cryptographic primitives are very resource consuming operations.

In [17], Zhang et al. propose a node authentication protocol for hierarchical WSNs. The hierarchical topology is limited to a base station, cluster heads and sensor nodes. The cluster heads can reach the sensors of their clusters directly, and can also reach the base station directly. The authentication is based on hash chain functions and symmetric encryption. The proposed protocol is not resilient to insider attacks as cluster heads are trusted to forward join requests to base station. In addition, the coverage of the network is limited due to the limited number of hops in a hierarchical topology.

Many contributions have been made in the key establishment and symmetric key distribution in WSNs using symmetric cryptography and hash functions. Some of them are based on a probabilistic pre-distribution that guarantees that any two nodes in the network are able to share a key with a certain probability, and others are deterministic but cause more storage overhead [18]. They do not evaluate on real motes their solutions and the security analysis is only informal. One of the most known symmetric key systems that were proposed for wireless sensor networks is SPINS (Security Protocols for Sensor Networks) [19], which uses a simplified version of TESLA (Timed, Efficient, Streaming, Loss-tolerant Authentication) protocol [20]. Perrig et al. test several symmetric encryption functions and MAC (Message Authentication Code) for their protocols using an extremely limited sensor network platform. They show that data transmission takes 71% of the time. In SPINS, the base station plays an essential role in the key establishment process. It is a lightweight cryptography protocol but has limited scalability and depends heavily on the base station.

Munivel et al. in [21] propose a multi-hop key establishment between nodes called Micro-PKI, using ECC and MAC. Their method is based on the pre-distribution of the public key of the base station. Using this public key, every node is able to create a secret key with any other node of the network. They evaluate the energy consumption of their solution and perform an informal security analysis. The authentication process in this proposal is only dependent on the public key of the base station; if a node has this key, it is considered authenticated. This makes the procurement of this public key very critical for the whole security architecture.

In [22] Chan et al. propose PIKE (Peer Intermediaries for Key Establishment), one of the most famous key establishment protocols that is not dependent on a central trusted node. According to PIKE, symmetric keys are pre-deployed in the nodes in such a way to guarantee that any two nodes in the network have at least one node in common with which each one of the two nodes has a secret key with it. Therefore, these two nodes are able to establish a secret key by using the trusted channel established with the common node. They provide a simulation evaluation of the protocol and estimate the energy and memory cost of several schemes. They also give an informal security analysis of the protocol against node compromise. PIKE suffers from high memory storage to make sure that nodes are able to find at least one node in common to establish a new key.

CARPY and CARPY+ are proposed in [23]. They are based on the symmetric keys of Blom [24] with a perturbation function that makes it more difficult for an attacker to guess the pairwise keys. In their paper they discuss the five criteria proposed in [25] and claim that CARPY+ satisfies all of them. These criteria are:

-

Resilience to the Adversary’s Intervention during the key establishment phase,

-

Directed and Guaranteed Key Establishment for any couple of nodes in the network,

-

Resilience to Network Configurations, i.e., nodes should be able to establish keys in any kind of network topology,

-

Efficiency of the key establishment process in terms of memory storage, communication overhead and complexity,

-

Resilience to Dynamic Node Deployment, which allows nodes to be added at any time to the network and establish keys on demand.

The authors give a detailed security analysis including a security model to prove manually the resistance against a given number of compromised nodes. They have implemented their solutions on TelosB compatible mote to evaluate their performances. The main weakness of this scheme is the lack of a re-keying process. The pre-shared matrices will only help to create one pairwise key for every couple of nodes.

Comparing these protocols to determine which is the most suitable requires to possession of all different implementations on one platform. However, most of the implementations, if exist at all, are very platform-dependent, thus an implementation on one platform might not give reproducible results on another platform and might not even operate on incompatible platforms. For this reason, in this paper, we will not compare execution results between protocols. On the other hand, Table 1 summarizes a comparison between the related work schemes and our proposition. The comparison is based on some repudiated criteria in the WSNs area. As the table shows, Yu et al.’s scheme [23] is the closest to our schemes. The authors use TelosB motes to evaluate the energy consumption of the basic operations used in their schemes and they provide a large scale simulation for thousands of nodes based on these measurements.

In this paper, we did not compare our execution time results with other protocols from the state-of-the-art because, as stated in the related work section, implementations are dependent on hardware and system. In addition, they can be optimized for certain platforms, which makes the comparison unfair using different platforms and cryptographic primitives. In our proposition, we take into account the multi-hop factor for node authentication and key establishment, which is often neglected in existing propositions. Any node in the network is able to be authenticated by sending a request in a multi-hop manner towards the base station, or send a key establishment request towards a multi-hop neighbour. Finally, our main difference with other works is that we formally prove the security of all our protocols using the automatic verification tool Scyther [5].

Table 1. Comparison of related work schemes.

Proposed Scheme	Standard Algorithms	Cryptographic Technique	Simulation	Implementation	Verification
Perrig et al., 2002 [19]	yes	symmetric	none	Smart dust [26]	manual
Chan et al., 2005 [22]	not specified	symmetric	yes	none	none
Yu et al., 2009 [23]	not specified	symmetric	none	TelosB	manual
Munivel et al., 2010 [21]	yes	symmetric/asymmetric	none	none	none
Yeh et al., 2011 [14]	yes	symmetric/asymmetric	none	none	none
Zhang et al., 2012 [17]	not specified	symmetric	none	none	none
Al-mahmud et al., 2012 [12]	yes	symmetric/asymmetric	none	none	none
Han et al., 2012 [15]	not specified	symmetric/asymmetric	none	none	none
Manjusha et al., 2013 [16]	yes	symmetric/asymmetric	MATLAB	none	none
Our schemes	yes	symmetric/asymmetric	none	TelosB	automatic

Table 1. Comparison of related work schemes.

Proposed Scheme	Standard Algorithms	Cryptographic Technique	Simulation	Implementation	Verification
Perrig et al., 2002 [19]	yes	symmetric	none	Smart dust [26]	manual
Chan et al., 2005 [22]	not specified	symmetric	yes	none	none
Yu et al., 2009 [23]	not specified	symmetric	none	TelosB	manual
Munivel et al., 2010 [21]	yes	symmetric/asymmetric	none	none	none
Yeh et al., 2011 [14]	yes	symmetric/asymmetric	none	none	none
Zhang et al., 2012 [17]	not specified	symmetric	none	none	none
Al-mahmud et al., 2012 [12]	yes	symmetric/asymmetric	none	none	none
Han et al., 2012 [15]	not specified	symmetric/asymmetric	none	none	none
Manjusha et al., 2013 [16]	yes	symmetric/asymmetric	MATLAB	none	none
Our schemes	yes	symmetric/asymmetric	none	TelosB	automatic

3. Pre-deployed Keys and Cryptographic Notations

Before deployment, each node N knows the public key $pk\left(S\right)$ of the sink S and also its own pair of public and private keys, denoted $\left(pk\right(N),sk(N\left)\right)$ respectively. Based on ECC (Elliptic Curve Cryptography), we have that $pk\left(N\right)=sk\left(N\right)\times G$, where G is a public generator point of the elliptic curve. Using this material, each node N can compute a shared key with the sink S using a variation of the Diffie–Hellman key exchange without interaction between the nodes, denoted $K_{DH}(N,S)$. These computations can be done by the sink and by all nodes before deployment in order to preserve their energy.

• The sink knows its own secret key $sk\left(S\right)$ and the public key $pk\left(N\right)$ of a node N. The sink computes $K_{DH}(N,S)=sk\left(S\right)\times pk\left(N\right)$.
• Node N multiplies its secret key $sk\left(N\right)$ by the public key of the sink $pk\left(S\right)$ to get $K_{DH}(N,S)$.

Both computations give the same shared key since:

$$K_{DH}(N,S)=sk\left(N\right)\times pk\left(S\right)=sk\left(N\right)\times (sk\left(S\right)\times G)=(sk\left(N\right)\times G)\times sk\left(S\right)=pk\left(N\right)\times sk\left(S\right)$$

In what follows, we use the following notations to describe exchanged messages in our protocols:

• I: a new node that initiates the protocol,
• N: a neighbour of node I,
• R: a node multi-hop away from I called responder,
• S: the sink of the network (also called base station),
• T: a trusted node between the initiator node I and the responder node R (T shares a session key with I and R),
• $n_A$: a nonce generated by node A,
• ${\left\{x\right\}}_k$: the encryption of message x with the symmetric or asymmetric key k,
• $pk\left(A\right)$: the public key of node A,
• $sk\left(A\right)$: the secret (private) key of node A,
• $K(I,S)$: the session key between I and S,
• $K_{DH}(N,S)$: the shared symmetric key between N and S using the Diffie–Hellman key exchange without interaction described above.

In the next section, we recall two protocols that allow a node to join a multi-hop WSN in a secure way and establish secure links with the sink and a neighbour node. A new node is able to establish a secure link with the nearest node that is already part of the network. Then in the following sections, we propose six other protocols that allow any node to establish secure links with any another node in its multi-hop neighbourhood. Two protocols use the sink for key establishment and four protocols establish new keys without resort to the sink. In all figures that describe our protocol, we denote a direct communication by an arrow between two nodes, and denote a communication passing by several possible intermediate nodes by a dotted arrow. We also explicate the size of each exchanged message in Bytes.

4. Authenticated Multi-hop Join Protocols: $DJS$ and $IJS$

In this section, for the sake of completeness and to make the paper self-sufficient, we recall the authenticated multi-hop join protocols that our key establishment protocols are based upon. Protocol $DJS$ (Direct Join to the Sink), presented in Figure 1, was presented in [11]. It allows new nodes in range of the sink to join the network directly. A new node I sends a direct request to S in order to establish a session key with it. Node I begins the join process by computing the symmetric key $K_{DH}(I,S)$ with the sink S. Then, node I generates a nonce $n_I$ and adds its identity in order to form the request {$n_I$, I}. The request is encrypted with $K_{DH}(I,S)$ and sent to S. Upon reception, in order to decrypt the request, S computes $K_{DH}(I,S)$ using the public key of I. Then, S verifies the identity of I by checking if the identity of I belongs to the list of authorized nodes, and generates a new session key $K(I,S)$. The join response contains $n_I$, the identity of S and the new symmetric session key. The response is encrypted using $pk\left(I\right)$ and is sent to I. Only I is able to decrypt the response with its secret key $sk\left(I\right)$. We note that $n_I$ helps I to authenticate the response message of S.

Figure 1. $DJS$: node I joins the network by communicating directly with the sink S.

Figure 1. $DJS$: node I joins the network by communicating directly with the sink S.

The protocol $IJS$ (Indirect Join to the Sink), presented in Figure 2, was also presented in [11] and allows a new node to join the network through a neighbour node N. The new node I sends an indirect request to S in order to be authenticated and to establish a session key with N. Node N forwards the request to S through intermediate nodes. We note that the request and the response are just forwarded by these nodes without being modified. They are unable to decrypt either the request part or the response part of the message; only nodes I and S are able to decrypt messages encrypted with $K_{DH}(I,S)$, and only N and S are able to decrypt the messages encrypted with $K_{DH}(N,S)$.

Figure 2. $IJS$: I joins the network through N. Intermediate nodes between N and S forward messages without any encryption or decryption.

Figure 2. $IJS$: I joins the network through N. Intermediate nodes between N and S forward messages without any encryption or decryption.

Our aim is to establish a shared key between any two authenticated nodes I and R of the network (not necessary in range). We propose six different protocols, called $MK{E}_S$, $MK{E}_S-light$, $MK{E}_T-a$, $MK{E}_T-b$, $MK{E}_T-c$ and $MK{E}_T-d$.

5. Multi-hop Key Establishment Protocols Using the Sink

We start by explaining protocol $MK{E}_S$ and its optimization $MK{E}_S-light$. They both use the sink to establish a new key between two nodes. Protocol $MK{E}_S$, depicted in Figure 3, uses the shared symmetric keys $K_{DH}(I,S)$ and $K_{DH}(R,S)$ computed before the deployment between any node in the network and the sink S. These shared keys are used to communicate the public keys of I and R. We consider that the sink knows all the public keys of all nodes and a node only knows its public key and the public of the sink. The initiator node I builds a request containing the identity of node R and a nonce $n_I$. This request is encrypted with $K_{DH}(I,S)$ and sent to S. The sink S sends

• to R, the identity of I, a nonce $n_S$, the nonce $n_I$ received from I and the public key of I encrypted with the shared symmetric key $K_{DH}(S,R)$.
• to I, the identity of R, the same nonce $n_S$, the public key of R encrypted with the shared symmetric key $K_{DH}(I,S)$,

Once these two messages are received by I and R, the two nodes are able to compute $K_{DH}(I,R)$ as follows:

• Node I computes $sk\left(I\right)\times pk\left(R\right)=sk\left(I\right)\times sk\left(R\right)\times G=K_{DH}(I,R)$.
• Node R computes $sk\left(R\right)\times pk\left(I\right)=sk\left(R\right)\times sk\left(I\right)\times G=K_{DH}(I,R)$.

Figure 3. $MK{E}_S$: Multi-hop Key Establishment using the sink S to deliver public keys. $K_{DH}(I,R)$ is computed by the initiator I and the responder R.

Figure 3. $MK{E}_S$: Multi-hop Key Establishment using the sink S to deliver public keys. $K_{DH}(I,R)$ is computed by the initiator I and the responder R.

The mutual authentication of R and I is ensured using the sink S as the trusted third party. Indeed, only S in this protocol is able to deliver public keys to nodes. The authentication between nodes is done by the verification of nonces. Node R verifies that the received nonces $n_I$ and $n_S$ from S are the same as the ones sent by I. Then, node R confirms the establishment of $K_{DH}(I,R)$, by sending $n_I$ and $n_S$ to the initiator I encrypted with $K_{DH}(I,R)$. Upon reception, node I verifies first its own nonce and if $n_S$ received from R is the same as the one sent by the sink.

Notice that the computation of the new key $K_{DH}(I,R)$ can be done by the sink in order to save some computations on nodes R and I. Instead of sending the respective public keys, the sink generates the new shared key and sends it to the two nodes. Indeed, the sink is the trusted entity that generated and distributed the public/private keys to all nodes in the first place during the pre-deployment phase. Another possibility would be to generate symmetric keys at the sink using any standard random key generation function. In this version, we chose to use the $DH$ method at the sink. This version, called $MK{E}_S-light$, is depicted in Figure 4.

Figure 4. $MK{E}_S-light$: Multi-hop Key Establishment using the sink S to compute and deliver $K_{DH}(I,R)$ to the initiator and the responder.

Figure 4. $MK{E}_S-light$: Multi-hop Key Establishment using the sink S to compute and deliver $K_{DH}(I,R)$ to the initiator and the responder.

6. Multi-hop Key Establishment Protocols without the Sink

We propose four protocols that use a trusted intermediate node T instead of the sink S to establish a new key. The main idea is to allow other nodes to authenticate new key establishment. In this way, we avoid exhausting the sink and we preserve energy of its neighbours that are relaying requests all the time. Doing so also helps to avoid traffic congestion around the sink. When other nodes share this role, the traffic for key establishment will be spread throughout the network.

A node T is considered as trusted by a node I if nodes I and T have at least one secret key in common. This secret key is previously established either during the join process or using protocol $MK{E}_S$. Indeed, if node I has a secret key with T, it means that I has joined the network through T (or vice versa) or has established a new key with node T using $MK{E}_S$ (or $MK{E}_S-light$). Node T might have the public key of both nodes I and R, have only one of the two public keys, or have neither, according to the protocol that has served for the secret key establishment. In order to establish a secret key, an initiator node I first tries to find a common trusted node T with the responder R. This discovery mechanism is out of the scope of this paper, and can be done using one of the several existing secure routing protocols such as SDSR [27]. We describe the four possible situations according to the knowledge of node T:

• if T has both $pk\left(I\right)$ and $pk\left(R\right)$, then I follows protocol $MK{E}_T-a$,
• if T has $pk\left(R\right)$ but not $pk\left(I\right)$, then I follows protocol $MK{E}_T-b$,
• if T has $pk\left(I\right)$ but not $pk\left(R\right)$, then I follows protocol $MK{E}_T-c$,
• if T has neither $pk\left(I\right)$ nor $pk\left(R\right)$, then I follows protocol $MK{E}_T-d$.

Note that if T does not exist, then I follows $MK{E}_S$ or $MK{E}_S-light$. We note that these four protocols are very useful when nodes are located far from the sink. Indeed, it preserves the energy of intermediate nodes between I and S and those between R and S. We explain the main difference between our four variations of the multi-hop key establishment:

• In protocol $MK{E}_T-a$ (Figure 5), the trusted node T possesses $pk\left(I\right)$ and $pk\left(R\right)$. Therefore, protocols $MK{E}_T-a$ and $MK{E}_S$ are very similar. We note two differences: the sink S of $MK{E}_S$ is replaced by the trusted node T, and the messages exchanged between both nodes and S are encrypted using the session keys established after deployment instead of using shared keys computed before deployment. After receiving a request from the initiator I, the trusted node T delivers $pk\left(R\right)$ to I and $pk\left(I\right)$ to R.
• In protocol $MK{E}_T-b$, the trusted node T possesses $pk\left(R\right)$ but not $pk\left(I\right)$. Protocol $MK{E}_T-b$ is the same as protocol $MK{E}_T-a$ except that the first message sent by I is replaced by ${\{R,n_I,pk\left(I\right)\}}_{K(I,T)}$. Indeed, since T does not possess the public key of node I, I should send it to T in order to send it to R.
• In protocol $MK{E}_T-c$ (Figure 6), the trusted node T possesses $pk\left(I\right)$ but not $pk\left(R\right)$. After receiving $pk\left(I\right)$ from T, the responder R sends its own public key to T in order to send it to I.
• In protocol $MK{E}_T-d$, the trusted node T possesses neither $pk\left(I\right)$ nor $pk\left(R\right)$. Protocol $MK{E}_T-d$ is the same as protocol $MK{E}_T-c$ except that the first message sent by I is replaced by ${\{R,n_I,pk\left(I\right)\}}_{K(I,T)}$. Node I sends $pk\left(I\right)$ to T in its request in order to send it to R.

Note that the last two messages have the same role in all proposed protocols. These messages are used to verify nonces and confirm the establishment of the shared key $K_{DH}(I,R)$. In addition, in order for node R to know if it needs to include its public key in the reply to T or not, it can keep a record of how it obtained the shared key with T and react accordingly. Alternatively, we can add in the header of the message sent from T to R the identifier of the protocol used for the key establishment. In both cases, the description of the protocols remains the same.

Figure 5. $MK{E}_T-a$: Multi-hop Key Establishment using a trusted node T to deliver public keys. T possesses $pk\left(I\right)$ and $pk\left(R\right)$. The key $K_{DH}(I,R)$ is computed by the initiator I and the responder R.

Figure 5. $MK{E}_T-a$: Multi-hop Key Establishment using a trusted node T to deliver public keys. T possesses $pk\left(I\right)$ and $pk\left(R\right)$. The key $K_{DH}(I,R)$ is computed by the initiator I and the responder R.

Figure 6. $MK{E}_T-c$: Multi-hop Key Establishment using a trusted node T to deliver public keys. T possesses $pk\left(I\right)$ but not $pk\left(R\right)$. $K_{DH}(I,R)$ is computed by the initiator I and the responder R.

Figure 6. $MK{E}_T-c$: Multi-hop Key Establishment using a trusted node T to deliver public keys. T possesses $pk\left(I\right)$ but not $pk\left(R\right)$. $K_{DH}(I,R)$ is computed by the initiator I and the responder R.

7. Key Dependency

It is important to note that cryptographic keys are interdependent. In order for a certain protocol to be executed, nodes should have the appropriate keys. In this section we recapitulate the dependency between the keys for each of our protocols.

Table 2 presents the dependency between keys for each of our protocols. The public/private keys of nodes are used to compute the shared symmetric keys using Diffie–Hellman without interaction described in Section 3. These shared keys are then used to deliver public keys in the case of protocols $IJS$ and $MK{E}_S$, or to deliver the pre-computed Diffie–Hellman key in the case of protocol $MK{E}_S-light$. In protocols $MK{E}_T-a$, $MK{E}_T-b$, $MK{E}_T-c$and $MK{E}_T-d$, the public keys of I and R are delivered using the session keys between these nodes and T. For example, in protocol $MK{E}_T-a$, the key $pk\left(R\right)$ is encrypted by T using the key $K(I,T)$ in order to deliver it to I, which is denoted by $K(I,T)\stackrel{T:I}{⟶}pk\left(R\right)$. Similarly, in this protocol $pk\left(I\right)$ is encrypted by T using the key $K(R,T)$ in order to deliver it to R, which is denoted by $K(R,T)\stackrel{T:R}{⟶}pk\left(I\right)$.

Table 2. Key dependency in our protocols. $K_1\stackrel{A:B}{⟶}{K}_2$ denotes that K₂ is delivered by A to B and encrypted with K₁.

Protocol Name	Delivering
$DJS$	$pk\left(I\right)\stackrel{S:I}{⟶}K(I,S)$
$IJS$	$K_{DH}(N,S)\stackrel{S:N}{⟶}pk\left(I\right)\stackrel{N:I}{⟶}K(I,N)$
$MK{E}_S$	$K_{DH}(I,S)\stackrel{S:I}{⟶}pk\left(R\right)$
	$K_{DH}(R,S)\stackrel{S:R}{⟶}pk\left(I\right)$
$MK{E}_S-light$	$K_{DH}(I,S)\stackrel{S:I}{⟶}{K}_{DH}(I,R)$
	$K_{DH}(R,S)\stackrel{S:R}{⟶}{K}_{DH}(I,R)$
$MK{E}_T-a$	$K(I,T)\stackrel{T:I}{⟶}pk\left(R\right)$
	$K(R,T)\stackrel{T:R}{⟶}pk\left(I\right)$
$MK{E}_T-b$	$K(I,T)\stackrel{I:T}{⟶}pk\left(I\right)$
	$K(I,T)\stackrel{T:I}{⟶}pk\left(R\right)$
	$K(R,T)\stackrel{T:R}{⟶}pk\left(I\right)$
$MK{E}_T-c$	$K(R,T)\stackrel{T:R}{⟶}pk\left(I\right)$
	$K(R,T)\stackrel{R:T}{⟶}pk\left(R\right)$
	$K(I,T)\stackrel{T:I}{⟶}pk\left(R\right)$
$MK{E}_T-d$	$K(I,T)\stackrel{I:T}{⟶}pk\left(I\right)$
	$K(R,T)\stackrel{T:R}{⟶}pk\left(I\right)$
	$K(R,T)\stackrel{R:T}{⟶}pk\left(R\right)$
	$K(I,T)\stackrel{T:I}{⟶}pk\left(R\right)$

Table 2. Key dependency in our protocols. $K_1\stackrel{A:B}{⟶}{K}_2$ denotes that K₂ is delivered by A to B and encrypted with K₁.

Protocol Name	Delivering
$DJS$	$pk\left(I\right)\stackrel{S:I}{⟶}K(I,S)$
$IJS$	$K_{DH}(N,S)\stackrel{S:N}{⟶}pk\left(I\right)\stackrel{N:I}{⟶}K(I,N)$
$MK{E}_S$	$K_{DH}(I,S)\stackrel{S:I}{⟶}pk\left(R\right)$
	$K_{DH}(R,S)\stackrel{S:R}{⟶}pk\left(I\right)$
$MK{E}_S-light$	$K_{DH}(I,S)\stackrel{S:I}{⟶}{K}_{DH}(I,R)$
	$K_{DH}(R,S)\stackrel{S:R}{⟶}{K}_{DH}(I,R)$
$MK{E}_T-a$	$K(I,T)\stackrel{T:I}{⟶}pk\left(R\right)$
	$K(R,T)\stackrel{T:R}{⟶}pk\left(I\right)$
$MK{E}_T-b$	$K(I,T)\stackrel{I:T}{⟶}pk\left(I\right)$
	$K(I,T)\stackrel{T:I}{⟶}pk\left(R\right)$
	$K(R,T)\stackrel{T:R}{⟶}pk\left(I\right)$
$MK{E}_T-c$	$K(R,T)\stackrel{T:R}{⟶}pk\left(I\right)$
	$K(R,T)\stackrel{R:T}{⟶}pk\left(R\right)$
	$K(I,T)\stackrel{T:I}{⟶}pk\left(R\right)$
$MK{E}_T-d$	$K(I,T)\stackrel{I:T}{⟶}pk\left(I\right)$
	$K(R,T)\stackrel{T:R}{⟶}pk\left(I\right)$
	$K(R,T)\stackrel{R:T}{⟶}pk\left(R\right)$
	$K(I,T)\stackrel{T:I}{⟶}pk\left(R\right)$

8. Formal Security Evaluation

Evaluating the security of cryptographic protocols is not an easy task and flaws can readily occur in protocols. During the past decades, several tools [3,5,28] have been developed to automatically verify cryptographic protocols. We use Scyther [5] because it is one of the fastest as has been shown in [29] and also one of the most user friendly.

Cas Cremers has developed an automatic tool called Scyther [5]. It is a free tool available on all operating systems (Linux, Mac and Windows). This tool can automatically find attacks on cryptographic protocols and prove their security for bounded and unbounded numbers of sessions. One main advantage of Scyther is that it provides an easy way to model security properties like secrecy and authentication.

Scyther uses the Dolev–Yao intruder model [6]. In this model, the intruder controls the network and all communications pass through it, which means that all packets can be captured by the intruder. This is why we do not consider multiple forwarder nodes in our analysis, since it does not provide more security. Moreover, the intruder has its own public and secret pairs of keys, enabling it to play the role of any participant in the protocol. It can also encrypt messages with all public or symmetric keys that it knows and it decrypts cipher texts only if it knows the decryption key. We verified all our protocols using Scyther without any intermediate nodes. When Scyther proves a security property, the tool only outputs “OK”, meaning that the property is satisfied. However, if there is a flaw, then a graphical description of the discovered attack is given and the attack is automatically generated. More precisely, we proved the secrecy of all sensitive data exchanged (keys and nonces) and also the authenticity of the communication. Our Scyther codes are available at [9]. The secrecy of the keys and the nonces means that an intruder cannot learn these data. The authentication property of the communication means that each node does indeed communicate with the expected node. This property protects our protocols from replay or man-in-the-middle attacks. Our protocols might appear simple, but they are the result of an optimization process using Scyther. It leads us to minimal protocol in the sense that removing any piece of information in any message will enable an attack.

9. Evaluations

In order to compare the execution time of our different protocols, we implemented each protocol on TelosB motes. In what follows, we describe the settings of our testbed. We also provide and discuss the results of the overhead of each protocol. We did not compare our protocols with other existing protocols because implementations are very heterogeneous. Implementation on sensor nodes is very hardware-dependent; optimization can be done for certain functions depending on the capacities and the design of the hardware. Thus comparing different implementations on different motes is not really conclusive, as is shown in [30,31,32,33]. The same applies for comparison by simulation, which is even less conclusive because simulation does not give an idea about how complex the operations are.

TelosB motes have an 8 MHz microcontroller with 10 KB of RAM, 48 KB of ROM and a CC2420 radio using the IEEE 802.15.4 standard. In our evaluation, we use public key Elliptic Curve Cryptography (ECC), with parameters secp160r1 given by the Standards for Efficient Cryptography Group. Our implementation of ECC on TelosB is based on the TinyECC library [34]. More precisely, we use Elliptic Curve Integrated Encryption Scheme (ECIES), the public key encryption system proposed by Victor Shoup in 2001, and the Elliptic Curve Diffie–Hellman (ECDH) key agreement scheme [35]. For all symmetric encryptions, we use an optimized implementation of AES [36] with a 128-bit key proposed by [37] in CTR mode. In order to explain why we choose AES with CTR mode and the 128-bit key k, we recall the mechanism of this scheme: let us consider a message m composed of p blocks $m_1\left|\right|m_2\left|\right|\dots \left|\right|m_p$, and an initial counter value $IV$ randomly chosen. The cipher of the block $m_i$ is $c_i={\{IV+i\}}_k\oplus m_i$, where ⊕ denotes the bitwise XOR operator. If one knows $IV$ and the key k, then one can easily recover from $c_i$ the message $m_i={\{IV+i\}}_k\oplus c_i$. When the size of the last block $m_p$ is smaller than 128 bits, it is usual to pad it with 0s to reach 128 bits in order to let both operands have the same length to perform the bitwise XOR. In this case, the size of the transmitted encrypted packets is always a multiple of 128 bits. However, in the CTR mode, we can just cut the ${\{IV+p\}}_k$ message to the size of $m_p$. Hence we can transmit encrypted messages with exactly the same size as the original message, and therefore save some execution time.

During the experiments, we considered topologies without intermediate nodes, since these nodes would only forward the packets without doing any modification on the packets. The cost of these communications is therefore dependent on the network density, topology and traffic load. In this paper, we only consider a minimal topology containing only the nodes involved in the cryptographic operations. This means that for all protocols we tested them with a topology of 3 nodes, except for $DJS$ where only 2 nodes were needed for the execution. This does not affect the feasibility of our protocols for more hops, because adding more intermediate nodes does not add more cryptographic operations—intermediate nodes will only forward the message to the next hop according the routing protocol. In addition, nodes do not have other traffic to exchange during the execution of the protocols. Of course, additional overhead should be considered because of the routing process and exchanged messages, but this is very dependent on the routing and MAC layers used during the evaluation. For this reason, we preferred to include only overhead induced by the cryptographic operations and not the overhead induced by the network protocols.

In the Table 3, we provide the real execution time for all our protocols. For the sake of completeness and to make the paper self-sufficient, we also included the results of $DJS$ and $IJS$. These results are the averages of 100 experiments. We added in the table the standard deviation of these averages.

Table 3. Total execution time and total size of exchanged messages of our protocols using a 160-bit ECIES key and a 128-bit AES-CTR key.

Protocol Name	Execution Time on the Testbed (ms)	Standard Deviation (ms)	Message Size (Bytes)
$DJS$	10,112.62	78.09	066
$IJS$	10,180.81	111.94	116
$MK{E}_S$	06828.48	005.96	119
$MK{E}_S-light$	03649.74	006.10	071
$MK{E}_T-a$	06831.18	006.76	119
$MK{E}_T-b$	06950.10	005.77	159
$MK{E}_T-c$	07324.88	007.77	177
$MK{E}_T-d$	07447.32	008.61	217

Table 3. Total execution time and total size of exchanged messages of our protocols using a 160-bit ECIES key and a 128-bit AES-CTR key.

Protocol Name	Execution Time on the Testbed (ms)	Standard Deviation (ms)	Message Size (Bytes)
$DJS$	10,112.62	78.09	066
$IJS$	10,180.81	111.94	116
$MK{E}_S$	06828.48	005.96	119
$MK{E}_S-light$	03649.74	006.10	071
$MK{E}_T-a$	06831.18	006.76	119
$MK{E}_T-b$	06950.10	005.77	159
$MK{E}_T-c$	07324.88	007.77	177
$MK{E}_T-d$	07447.32	008.61	217

Moreover, the differences in our protocols come from the usage of cryptographic primitives. All protocols using asymmetric encryption ($DJS$ and $IJS$) require more execution time than protocols using only symmetric encryption ($MK{E}_S$, $MK{E}_S-light$, $MK{E}_T-a$, $MK{E}_T-b$, $MK{E}_T-c$ and $MK{E}_T-d$). In what follows, we analyze the results:

• Note that the two slowest protocols are the join protocols proposed in [11]. Hence, it is more efficient to establish keys after the deployment than to rejoin the network.
• Protocols $MK{E}_S$ and $MK{E}_T-a$ have practically the same execution time. The small difference comes from the use of symmetric keys established after the deployment instead of symmetric shared keys computed before deployment.
• Protocol $MK{E}_S-light$ is the fastest protocol because the sink computes $K_{DH}(I,R)$ and delivers it to I and R in order to save their energy.
• Protocols $MK{E}_T-c$ and $MK{E}_T-d$ are slower than $MK{E}_S$, $MK{E}_T-a$ and $MK{E}_T-b$ due to the additional messages sent from R to S containing the public key of R.
• The difference of execution time between $MK{E}_T-a$ and $MK{E}_T-b$, on one side, and $MK{E}_T-c$ and $MK{E}_T-d$, on the other side, is almost equal to 130 ms. This is due to the encryption, decryption and transmission of $pk\left(I\right)$ added to the request message sent by node I.
• In Table 3, we also provide the total size in $Bytes$ of all exchanged messages for each protocol. In the figures of protocols presented in Section 4 and Section 6, the size in $Bytes$ is also tagged at the bottom of each message. We have fixed the size of the identity of a node to 1 $Byte$ and the size of a nonce to 4 $Bytes$. It should be noted that the size of $K_{DH}(I,R)$ is fixed to 16 $Bytes$. Indeed, the result of computation of $pk\left(I\right)\times sk\left(R\right)$ gives a key length of 20 $Bytes$. We use the first 16 $Bytes$ of the computation result for $K_{DH}(I,R)$.
• Also note that we use symmetric encryption in all protocols for key establishment of Section 6. Therefore, the size of the input message in $Bytes$ is the same as the size of the output message. In contrast, we use both asymmetric encryption and symmetric encryption in the two join protocols of Section 4. Therefore, in order to obtain the tagged value of message size, we must add to the output encrypted message the size of the MAC, which is equal to 20 $Bytes$. For example, the total size of last message in Figure 1 sent to I is 66 $Bytes$, containing $n_I$($4Bytes$), S ($1Byte$), $K(I,S)$ ($16Bytes$) and a MAC ($20Bytes$).

Notice that the standard variation values are small compared with the execution time of the protocol. These variations are essentially caused by the various interruptions of the micro-controller. Nevertheless, we can see that the highest standard deviation values are obtained for protocols using public key encryption ($DJS$ and $IJS$). These complex computations take more time and for each experiment the execution time can vary a little bit more. Indeed, the public encryption starts with a random number generation and then multiplies it with the generator point of the curve. The multiplication operation takes undetermined time, depending on the random number that was chosen. This explains the larger variation in the results for protocols $DJS$ and $IJS$.

In order to verify the cause of this variation, we made 100 iterations for protocols $DJS$ and $IJS$ using the same random number. Table 4 shows that when we fix the random number, the obtained standard variation is considerably reduced and becomes equivalent to that of the other protocols. This shows that the value of the random number affects the overall execution time of $DJS$ and $IJS$. Note that the averages in Table 4 are not the same as the averages in Table 3, which is normal because the averages in Table 3 are over 100 iterations with 100 different random numbers. The size of the fixed random number used in the experiments is $20bytes$. The hexadecimal values of each byte starting with most significant byte are: $da$ 52 $cd$ $de$ 28 $d5$ $c5$ $2a$ $8b$ $5c$ 18 $b9$ 28 $3f$ $1a$ 68 $b7$ $2d$ 01 $7b$.

Table 4. Total execution time for protocols $DJS$ and $IJS$ using the same random number in ECIES encryption.

Protocol Name	Execution Time on the Testbed (ms)	Standard Deviation (ms)
$DJS$	10,186.49	5.94
$IJS$	10,291.24	5.71

Table 4. Total execution time for protocols $DJS$ and $IJS$ using the same random number in ECIES encryption.

Protocol Name	Execution Time on the Testbed (ms)	Standard Deviation (ms)
$DJS$	10,186.49	5.94
$IJS$	10,291.24	5.71

10. Attack Detection Perspective

Based on the overhead estimation of our protocol, we are able to allow nodes to detect certain types of attack attempts. Indeed, when a node is attempting an attack, it will induce additional overhead due to the execution time of cryptographic operations that the attacker needs. Moreover, even in the man-in-the-middle attack, the wormhole attack or the replay attack, the attacker needs to listen, forward or generate some encrypted messages. All these operations will cause an additional delay to the estimated overall request/reply procedure of the authenticated join protocol or key establishment protocol. We assume that the attacker has the same processing capacities of the nodes; in other words, we assume that an intruder was able to control one or more nodes of the network and is trying to launch the attack using the compromised nodes.

The attacks that this technique is able to detect are the ones that will introduce additional delay to the process. For example, the node that is requesting to join the network will be waiting for an authenticated response. This response should be received before a certain timeout expires. This timeout can be estimated according to the number of hops that separate the new node from the sink and the type of protocol that is used to join the network.

For example, if the new node is 5 hops away from the sink, with a 160-bit key, it will take $6834.20$ plus the end-to-end communication delay for a node to establish a key with another node in the network by passing through the sink ($MK{E}_S$). Indeed, the results shown in Table 3 represent the execution time without taking into consideration the end-to-end communication delay that is induced by the intermediate nodes. This delay can be estimated by the routing protocol and taken into account when calculating the estimated overall time of the process.

In order for the attack detection to be efficient, the end-to-end communication delay should remain considerably lower than the delay induced by additional cryptographic operations. Hence, according to the protocol that is being used, the new node is able to estimate when it is expected to receive its response. Therefore, if a node does not receive an answer on time, it can deduce that this delay might have been caused by an intruder and then decide to abort the current join process or key establishment process and try to restart it. This means that a reply will be discarded if received later than expected. This attack detection will help prevent a node from accepting late replies, and restart the process to ensure that the response is received within a certain timeout interval. Delay estimations should be done for each network configuration and deployment because they are affected by the traffic state and the congestion that might be present in the network. In this paper these estimations are out of scope and will be the subject of future work.

Also, in order for the detection to work, the new node should know how many hops it is away from the sink. This information can be obtained from the routing protocol. One way to obtain this information could be the following. When the new node decides to join the network, it will listen for signalling messages from neighbouring nodes. These signalling messages should contain how many hops the signalling node is away from the sink. This way, the new node is able to estimate the delay in receiving the response. In this simple approach, we do not consider the case where certain nodes will deliberately announce that they are farther away from the sink in order to delay the process or try to launch attacks. This kind of malicious behaviour is studied in [38], where the authors propose a solution based on the reputation of nodes. This kind of solutions could be applied to our protocols and are part of our future works.

11. Conclusions and Future Work

We proposed several multi-hop node authentication and key establishment protocols for WSNs. Our key establishment solutions can be split into two categories. First, we propose two solutions that use the sink as a trusted third party to establish a new key between two nodes of the network. Then, we proposed four protocols that use other nodes in the network as trusted third parties in order to establish a new key. We proved the security of all of our solutions using the automatic tool Scyther. Our protocols have very few cryptographic operations but are free of flaws as proven by Scyther. Moreover, we implemented and tested all our protocols on TelosB nodes in order to evaluate their execution time. The results show that according to the load of the network and according to the topology, one category might be more efficient than the others.

Based on our measurements, we were able to allow nodes to detect attack attempts from other nodes in the network by simply measuring the delay of response reception. Each node can expect how much time it should take to receive a response according to the protocol being used and the hops that separate it from the sink. In the case of excessive delay, the node presumes that an attack is taking place and terminates the protocol. This can be considered as a simple intrusion detection system.

In our future works, we plan on testing our protocols in more realistic platforms such as the IoT-LAB [39] platform. It would then elucidate how our different protocols would perform in a large scale network and how long it would take to establish the required secured links.

The decision to choose one or the other of the protocols could be dependent on the topology information that each node has. For example, if the sink has constrained resource, it would be preferable for nodes to choose another trusted third party node to establish new keys. The choice would be based on the number of hops that might separate nodes that want to establish a secure link between each other and the trusted third party. This kind of information could be built using a neighbour discovery protocol that allows nodes to share neighbourhood discovery in order to establish n-hop neighbourhood information (where n is the number of hops that nodes will be able to discover). A trade-off should be made between the cost of neighbourhood discovery and the gain of balancing key establishment overhead on a bigger number of nodes. Of course, more extensive neighbourhood information enables higher possibility to find trusted third parties. This study will be part of our future works.