## 6 On Control Messages Protection
### SeFLOOD: The Secure FLOOD  
In order to protect the integrity and confidentiality of the FLOOD protocol we have extended it into a new protocol called _secure FLOOD_ (SeFLOOD). SeFLOOD protects control messages by establishing link-layer pair-wise keys and encrypting control messages by means of these keys. SeFLOOD uses the cryptographic suite described in Section 5. More specifically, SeFLOOD protects confidentiality and integrity of any given control message \(m\) by computing \(E_{e}(m,\lfloor h(m)\rfloor_{t})\), where \(E(\cdot)\) is a block cipher used in CBC-CTS mode (see Section 5), \(\lfloor h(\cdot)\rfloor_{t}\) is a \(t\)-bits truncated hash function (see Section 5), and \(e\) is a symmetric key [24]. For the sake of brevity, in the following we will denote this cryptographic transformation by \(\left\langle m\right\rangle_{e}\). Upon receiving \(\left\langle m\right\rangle_{e}\), a node decrypts it by \(e\), verifies the digest, and checks whether \(m\) contains some fresh quantity (e.g., a time stamp or a nonce) [33]. If the decryption and all the checks are successful, then we say that the node _successfully receives_ the message. Otherwise, the message is discarded. Link-layer keys are distributed as follows. We assume that each pair of nodes \(u_{i}\) and \(u_{j}\), \(i\
eq j,\) secretly shares a _pairwise link key_\(\ell_{ij}\), which is used to protect unicast messages between \(u_{i}\) and \(u_{j}\). In order to distribute the link keys, we could use well-known key establishment schemes such as Elliptic curve Diffie-Hellman [34] or the Blundo scheme [35]. However, for both simplicity and efficiency, each node can be deployed with a _Link-Key Table_ (LKT) containing all the pair-wise link keys it shares with the other nodes. This solution has an \(O(n)\) storage overhead, where \(n\) is the number of nodes in the system. However, it is suitable for an underwater acoustic network such as the one considered in the UAN project because the number \(n\) of nodes is small and each node has enough memory to store the whole Link-Key Table LKT. For example, in the case of a 128 bits link key and a network composed of 1,024 nodes, the Link-Key Table memory occupancy amounts to 16 Kbytes. As a node is typically equipped with 2 GB memory, then the storage overhead for the LKT amounts to the 0.78% of the whole memory, which is negligible. Furthermore, we group nodes into _clusters_ as follows. For each node we define a cluster that is the set of nodes belonging to the node's broadcast domain. We denote by \(\mathcal{C}_{u}\) the cluster associated with node \(u\). It follows that we have as many clusters as nodes. Furthermore, a node may belong to one or more clusters. A given node \(u\) certainly belongs to \(C_{u}\). Furthermore, if \(v\) is a neighbour of \(u\), then \(u\in\mathcal{C}_{v}\) as well. Each cluster is associated to a _cluster key_, which is used to secure broadcast communication among nodes belonging to the same cluster. Every node \(u\) generates a _cluster key_\(c_{u}\) and distributes it to all the members of its cluster. Furthermore, every node maintains a _Cluster Key Table_ (CKT) that has one entry for each cluster the node belongs to. Such an entry stores the cluster key of the cluster corresponding to that entry. By construction, the number of entries of the CKT is less than, or equal to, the number of entries of the LKT. This means that CKT requires a negligible amount of memory for its storage as well. Cluster keys are established by means of the following _Cluster Key Distribution Protocol_ (CKDP). Every node carries out the CKDP before initiating the FLOOD protocol. Once the link-layer cluster keys have been established, nodes use these keys to protect the integrity and confidentiality of FLOOD control messages. The Cluster Key Distribution Protocol consists of the following messages.