## 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 \(MKE_{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 \(MKE_{S}\) (or \(MKE_{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(I)\) and \(pk(R)\), then \(I\) follows protocol \(MKE_{T}-a\),
* if \(T\) has \(pk(R)\) but not \(pk(I)\), then \(I\) follows protocol \(MKE_{T}-b\),
* if \(T\) has \(pk(I)\) but not \(pk(R)\), then \(I\) follows protocol \(MKE_{T}-c\),
* if \(T\) has neither \(pk(I)\) nor \(pk(R)\), then \(I\) follows protocol \(MKE_{T}-d\). Note that if \(T\) does not exist, then \(I\) follows \(MKE_{S}\) or \(MKE_{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 \(MKE_{T}-a\) (Figure 5), the trusted node \(T\) possesses \(pk(I)\) and \(pk(R)\). Therefore, protocols \(MKE_{T}-a\) and \(MKE_{S}\) are very similar. We note two differences: the sink \(S\) of \(MKE_{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(R)\) to \(I\) and \(pk(I)\) to \(R\). * In protocol \(MKE_{T}-b\), the trusted node \(T\) possesses \(pk(R)\) but not \(pk(I)\). Protocol \(MKE_{T}-b\) is the same as protocol \(MKE_{T}-a\) except that the first message sent by \(I\) is replaced by \(\{R,n_{I},pk(I)\}_{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 \(MKE_{T}-c\) (Figure 6), the trusted node \(T\) possesses \(pk(I)\) but not \(pk(R)\). After receiving \(pk(I)\) from \(T\), the responder \(R\) sends its own public key to \(T\) in order to send it to \(I\). * In protocol \(MKE_{T}-d\), the trusted node \(T\) possesses neither \(pk(I)\) nor \(pk(R)\). Protocol \(MKE_{T}-d\) is the same as protocol \(MKE_{T}-c\) except that the first message sent by \(I\) is replaced by \(\{R,n_{I},pk(I)\}_{K(I,T)}\). Node \(I\) sends \(pk(I)\) 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)\).