Full paper: Postscript, PS.GZ, PDF

Node-to-Node Key Agreement

 

A convenient method to bootstrap secure connections is public-key cryptography protocols for symmetric-key setup [2, 15]. Unfortunately, our resource-constrained sensor nodes prevent us from using computationally expensive public-key cryptography. Therefore, we need to construct our protocols solely from symmetric-key algorithms. Hence we design a symmetric protocol that uses the base station as a trusted agent for key setup.

Assume that the node $A$ wants to establish a shared secret session key $SK$_AB with node $B$. Since $A$ and $B$ do not share any secrets, they need to use a trusted third party $S$, which is the base station in our case. In our trust setup, both $A$ and $B$ share a secret key with the base station, $K$_AS and $K$_BS, respectively. The following protocol achieves secure key agreement as well as strong key freshness:

$A$ \to $B:N$_A,A B$\to$S:N_A,N_B,A,B,$MAC(K$_BS,N_A|N_B|A|B) S$\to$A:{SK_AB}₉₉₄K_AS,$MAC(K\text{'}$_AS,N_A|B|{SK_AB}₁K_AS) S$\to$B:{SK_AB}₁K_BS,$MAC(K\text{'}$_BS,N_B|A|{SK_AB}₁K_BS)

The protocol uses our SNEPprotocol with strong freshness. The nonces $N$_A and $N$_B ensure strong key freshness to both $A$ and $B$. The SNEPprotocol is responsible to ensure confidentiality (through encryption with the keys $K$_AS and $K$_BS) of the established session key $SK$_AB, as well as message authentication (through the MAC using keys $K\text{'}$_AS and $K\text{'}$_BS) to make sure that the key was really generated by the base station. Note that the MAC in the second protocol message helps defend the base station from denial-of-service attacks, so the base station only sends two messages to $A$ and $B$ if it received a legitimate request from one of the nodes.

A nice feature of the above protocol is that the base station performs most of the transmission work. Other protocols usually involve a ticket that the server sends to one of the parties which forwards it to the other node, which requires more energy for the nodes to forward the message.

The Kerberos key agreement protocol achieves similar properties, except that it does not provide strong key freshness [19, 23]. However, it would be straightforward to implement it with strong key freshness by using SNEPwith strong freshness.