A Secure Communication Suite for Underwater Acoustic Sensor Networks
Identifieur interne : 000566 ( Pmc/Corpus ); précédent : 000565; suivant : 000567A Secure Communication Suite for Underwater Acoustic Sensor Networks
Auteurs : Gianluca Dini ; Angelica Lo DucaSource :
- Sensors (Basel, Switzerland) [ 1424-8220 ] ; 2012.
Abstract
In this paper we describe a security suite for Underwater Acoustic Sensor Networks comprising both fixed and mobile nodes. The security suite is composed of a secure routing protocol and a set of cryptographic primitives aimed at protecting the confidentiality and the integrity of underwater communication while taking into account the unique characteristics and constraints of the acoustic channel. By means of experiments and simulations based on real data, we show that the suite is suitable for an underwater networking environment as it introduces limited, and sometimes negligible, communication and power consumption overhead.
Url:
DOI: 10.3390/s121115133
PubMed: 23202204
PubMed Central: 3522957
Links to Exploration step
PMC:3522957Le document en format XML
<record><TEI><teiHeader><fileDesc><titleStmt><title xml:lang="en">A Secure Communication Suite for Underwater Acoustic Sensor Networks</title>
<author><name sortKey="Dini, Gianluca" sort="Dini, Gianluca" uniqKey="Dini G" first="Gianluca" last="Dini">Gianluca Dini</name>
<affiliation><nlm:aff id="af1-sensors-12-15133"> Department of Ingegneria dell'Informazione, University of Pisa, Largo Lazzarino 1, 56100 Pisa, Italy</nlm:aff>
</affiliation>
</author>
<author><name sortKey="Duca, Angelica Lo" sort="Duca, Angelica Lo" uniqKey="Duca A" first="Angelica Lo" last="Duca">Angelica Lo Duca</name>
<affiliation><nlm:aff id="af2-sensors-12-15133"> Institute of Informatics and Telematics, National Research Council, Via Giuseppe Moruzzi 1, 56124 Pisa, Italy; E-Mail:<email>angelica.loduca@gmail.com</email>
</nlm:aff>
</affiliation>
</author>
</titleStmt>
<publicationStmt><idno type="wicri:source">PMC</idno>
<idno type="pmid">23202204</idno>
<idno type="pmc">3522957</idno>
<idno type="url">http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3522957</idno>
<idno type="RBID">PMC:3522957</idno>
<idno type="doi">10.3390/s121115133</idno>
<date when="2012">2012</date>
<idno type="wicri:Area/Pmc/Corpus">000566</idno>
<idno type="wicri:explorRef" wicri:stream="Pmc" wicri:step="Corpus" wicri:corpus="PMC">000566</idno>
</publicationStmt>
<sourceDesc><biblStruct><analytic><title xml:lang="en" level="a" type="main">A Secure Communication Suite for Underwater Acoustic Sensor Networks</title>
<author><name sortKey="Dini, Gianluca" sort="Dini, Gianluca" uniqKey="Dini G" first="Gianluca" last="Dini">Gianluca Dini</name>
<affiliation><nlm:aff id="af1-sensors-12-15133"> Department of Ingegneria dell'Informazione, University of Pisa, Largo Lazzarino 1, 56100 Pisa, Italy</nlm:aff>
</affiliation>
</author>
<author><name sortKey="Duca, Angelica Lo" sort="Duca, Angelica Lo" uniqKey="Duca A" first="Angelica Lo" last="Duca">Angelica Lo Duca</name>
<affiliation><nlm:aff id="af2-sensors-12-15133"> Institute of Informatics and Telematics, National Research Council, Via Giuseppe Moruzzi 1, 56124 Pisa, Italy; E-Mail:<email>angelica.loduca@gmail.com</email>
</nlm:aff>
</affiliation>
</author>
</analytic>
<series><title level="j">Sensors (Basel, Switzerland)</title>
<idno type="eISSN">1424-8220</idno>
<imprint><date when="2012">2012</date>
</imprint>
</series>
</biblStruct>
</sourceDesc>
</fileDesc>
<profileDesc><textClass></textClass>
</profileDesc>
</teiHeader>
<front><div type="abstract" xml:lang="en"><p>In this paper we describe a security suite for Underwater Acoustic Sensor Networks comprising both fixed and mobile nodes. The security suite is composed of a secure routing protocol and a set of cryptographic primitives aimed at protecting the confidentiality and the integrity of underwater communication while taking into account the unique characteristics and constraints of the acoustic channel. By means of experiments and simulations based on real data, we show that the suite is suitable for an underwater networking environment as it introduces limited, and sometimes negligible, communication and power consumption overhead.</p>
</div>
</front>
<back><div1 type="bibliography"><listBibl><biblStruct><analytic><author><name sortKey="Akyildiz, I F" uniqKey="Akyildiz I">I.F. Akyildiz</name>
</author>
<author><name sortKey="Pompili, D" uniqKey="Pompili D">D. Pompili</name>
</author>
<author><name sortKey="Melodia, T" uniqKey="Melodia T">T. Melodia</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Domingo, M" uniqKey="Domingo M">M. Domingo</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Ca Denas, A A" uniqKey="Ca Denas A">A.A. Ca′rdenas</name>
</author>
<author><name sortKey="Roosta, T" uniqKey="Roosta T">T. Roosta</name>
</author>
<author><name sortKey="Sastry, S" uniqKey="Sastry S">S. Sastry</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Yick, J" uniqKey="Yick J">J. Yick</name>
</author>
<author><name sortKey="Mukherjee, B" uniqKey="Mukherjee B">B. Mukherjee</name>
</author>
<author><name sortKey="Ghosal, D" uniqKey="Ghosal D">D. Ghosal</name>
</author>
</analytic>
</biblStruct>
<biblStruct></biblStruct>
<biblStruct><analytic><author><name sortKey="Jiang, H" uniqKey="Jiang H">H. Jiang</name>
</author>
<author><name sortKey="Feng, Y X" uniqKey="Feng Y">Y.X. Feng</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Yang, G" uniqKey="Yang G">G. Yang</name>
</author>
<author><name sortKey="Wei, Z" uniqKey="Wei Z">Z. Wei</name>
</author>
<author><name sortKey="Cong, Y" uniqKey="Cong Y">Y. Cong</name>
</author>
<author><name sortKey="Jia, D" uniqKey="Jia D">D. Jia</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Dong, Y" uniqKey="Dong Y">Y. Dong</name>
</author>
<author><name sortKey="Liu, P" uniqKey="Liu P">P. Liu</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Dong, Y" uniqKey="Dong Y">Y. Dong</name>
</author>
<author><name sortKey="Liu, P" uniqKey="Liu P">P. Liu</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Dong, Y" uniqKey="Dong Y">Y. Dong</name>
</author>
<author><name sortKey="Liu, P" uniqKey="Liu P">P. Liu</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Zhang, R" uniqKey="Zhang R">R. Zhang</name>
</author>
<author><name sortKey="Zhang, Y" uniqKey="Zhang Y">Y. Zhang</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Wang, W" uniqKey="Wang W">W. Wang</name>
</author>
<author><name sortKey="Kong, J" uniqKey="Kong J">J. Kong</name>
</author>
<author><name sortKey="Bhargava, B K" uniqKey="Bhargava B">B.K. Bhargava</name>
</author>
<author><name sortKey="Gerla, M" uniqKey="Gerla M">M. Gerla</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Zuba, M" uniqKey="Zuba M">M. Zuba</name>
</author>
<author><name sortKey="Shi, Z" uniqKey="Shi Z">Z. Shi</name>
</author>
<author><name sortKey="Peng, Z" uniqKey="Peng Z">Z. Peng</name>
</author>
<author><name sortKey="Cui, J H" uniqKey="Cui J">J.H. Cui</name>
</author>
<author><name sortKey="Zhou, S" uniqKey="Zhou S">S. Zhou</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Liu, Y" uniqKey="Liu Y">Y. Liu</name>
</author>
<author><name sortKey="Jing, J" uniqKey="Jing J">J. Jing</name>
</author>
<author><name sortKey="Yang, J" uniqKey="Yang J">J. Yang</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Liu, C G" uniqKey="Liu C">C.G. Liu</name>
</author>
<author><name sortKey="Chao, C H" uniqKey="Chao C">C.H. Chao</name>
</author>
<author><name sortKey="Leou, C W" uniqKey="Leou C">C.W. Leou</name>
</author>
<author><name sortKey="Li, J S" uniqKey="Li J">J.S. Li</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Cong, Y" uniqKey="Cong Y">Y. Cong</name>
</author>
<author><name sortKey="Yang, G" uniqKey="Yang G">G. Yang</name>
</author>
<author><name sortKey="Wei, Z" uniqKey="Wei Z">Z. Wei</name>
</author>
<author><name sortKey="Zhou, W" uniqKey="Zhou W">W. Zhou</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Dini, G" uniqKey="Dini G">G. Dini</name>
</author>
<author><name sortKey="Lo Duca, A" uniqKey="Lo Duca A">A. Lo Duca</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Caiti, A" uniqKey="Caiti A">A. Caiti</name>
</author>
<author><name sortKey="Calabr, V" uniqKey="Calabr V">V. Calabrò</name>
</author>
<author><name sortKey="Dini, G" uniqKey="Dini G">G. Dini</name>
</author>
<author><name sortKey="Lo Duca, A" uniqKey="Lo Duca A">A. Lo Duca</name>
</author>
<author><name sortKey="Munaf, A" uniqKey="Munaf A">A. Munafò</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Dini, G" uniqKey="Dini G">G. Dini</name>
</author>
<author><name sortKey="Lo Duca, A" uniqKey="Lo Duca A">A. Lo Duca</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Caiti, A" uniqKey="Caiti A">A. Caiti</name>
</author>
<author><name sortKey="Munaf, A" uniqKey="Munaf A">A. Munafó</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Stojanovic, M" uniqKey="Stojanovic M">M. Stojanovic</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Arkin, R" uniqKey="Arkin R">R. Arkin</name>
</author>
<author><name sortKey="Grupen, R" uniqKey="Grupen R">R. Grupen</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Arkin, R C" uniqKey="Arkin R">R.C. Arkin</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Menezes, A J" uniqKey="Menezes A">A.J. Menezes</name>
</author>
<author><name sortKey="Van Oorschot, P C" uniqKey="Van Oorschot P">P.C. van Oorschot</name>
</author>
<author><name sortKey="Vanstone, S A" uniqKey="Vanstone S">S.A. Vanstone</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Patron, P" uniqKey="Patron P">P. Patron</name>
</author>
<author><name sortKey="Petillot, Y" uniqKey="Petillot Y">Y. Petillot</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Fagiolini, A" uniqKey="Fagiolini A">A. Fagiolini</name>
</author>
<author><name sortKey="Pellinacci, M" uniqKey="Pellinacci M">M. Pellinacci</name>
</author>
<author><name sortKey="Valenti, G" uniqKey="Valenti G">G. Valenti</name>
</author>
<author><name sortKey="Dini, G" uniqKey="Dini G">G. Dini</name>
</author>
<author><name sortKey="Bicchi, A" uniqKey="Bicchi A">A. Bicchi</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Schneier, B" uniqKey="Schneier B">B. Schneier</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Karlof, C" uniqKey="Karlof C">C. Karlof</name>
</author>
<author><name sortKey="Sastry, N" uniqKey="Sastry N">N. Sastry</name>
</author>
<author><name sortKey="Wagner, D" uniqKey="Wagner D">D. Wagner</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Dini, G" uniqKey="Dini G">G. Dini</name>
</author>
<author><name sortKey="Savino, I M" uniqKey="Savino I">I.M. Savino</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Dini, G" uniqKey="Dini G">G. Dini</name>
</author>
<author><name sortKey="Savino, I M" uniqKey="Savino I">I.M. Savino</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Rustad, H" uniqKey="Rustad H">H. Rustad</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Dijkstra, E W" uniqKey="Dijkstra E">E.W. Dijkstra</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Abadi, M" uniqKey="Abadi M">M. Abadi</name>
</author>
<author><name sortKey="Needham, R" uniqKey="Needham R">R. Needham</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Barker, E B" uniqKey="Barker E">E.B. Barker</name>
</author>
<author><name sortKey="Johnson, D" uniqKey="Johnson D">D. Johnson</name>
</author>
<author><name sortKey="Smid, M E" uniqKey="Smid M">M.E. Smid</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Blundo, C" uniqKey="Blundo C">C. Blundo</name>
</author>
<author><name sortKey="Santis, A D" uniqKey="Santis A">A.D. Santis</name>
</author>
<author><name sortKey="Herzberg, A" uniqKey="Herzberg A">A. Herzberg</name>
</author>
<author><name sortKey="Kutten, S" uniqKey="Kutten S">S. Kutten</name>
</author>
<author><name sortKey="Vaccaro, U" uniqKey="Vaccaro U">U. Vaccaro</name>
</author>
<author><name sortKey="Yung, M" uniqKey="Yung M">M. Yung</name>
</author>
</analytic>
</biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct><analytic><author><name sortKey="Pompili, D" uniqKey="Pompili D">D. Pompili</name>
</author>
<author><name sortKey="Akyildiz, I" uniqKey="Akyildiz I">I. Akyildiz</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Lampson, B W" uniqKey="Lampson B">B.W. Lampson</name>
</author>
</analytic>
</biblStruct>
</listBibl>
</div1>
</back>
</TEI>
<pmc article-type="research-article"><pmc-dir>properties open_access</pmc-dir>
<front><journal-meta><journal-id journal-id-type="nlm-ta">Sensors (Basel)</journal-id>
<journal-id journal-id-type="iso-abbrev">Sensors (Basel)</journal-id>
<journal-title-group><journal-title>Sensors (Basel, Switzerland)</journal-title>
</journal-title-group>
<issn pub-type="epub">1424-8220</issn>
<publisher><publisher-name>Molecular Diversity Preservation International (MDPI)</publisher-name>
</publisher>
</journal-meta>
<article-meta><article-id pub-id-type="pmid">23202204</article-id>
<article-id pub-id-type="pmc">3522957</article-id>
<article-id pub-id-type="doi">10.3390/s121115133</article-id>
<article-id pub-id-type="publisher-id">sensors-12-15133</article-id>
<article-categories><subj-group subj-group-type="heading"><subject>Article</subject>
</subj-group>
</article-categories>
<title-group><article-title>A Secure Communication Suite for Underwater Acoustic Sensor Networks</article-title>
</title-group>
<contrib-group><contrib contrib-type="author"><name><surname>Dini</surname>
<given-names>Gianluca</given-names>
</name>
<xref ref-type="aff" rid="af1-sensors-12-15133"><sup>1</sup>
</xref>
<xref ref-type="corresp" rid="c1-sensors-12-15133"><sup>*</sup>
</xref>
</contrib>
<contrib contrib-type="author"><name><surname>Duca</surname>
<given-names>Angelica Lo</given-names>
</name>
<xref ref-type="aff" rid="af2-sensors-12-15133"><sup>2</sup>
</xref>
</contrib>
</contrib-group>
<aff id="af1-sensors-12-15133"><label>1</label>
Department of Ingegneria dell'Informazione, University of Pisa, Largo Lazzarino 1, 56100 Pisa, Italy</aff>
<aff id="af2-sensors-12-15133"><label>2</label>
Institute of Informatics and Telematics, National Research Council, Via Giuseppe Moruzzi 1, 56124 Pisa, Italy; E-Mail:<email>angelica.loduca@gmail.com</email>
</aff>
<author-notes><corresp id="c1-sensors-12-15133"><label>*</label>
Author to whom correspondence should be addressed; E-Mail: <email>dini@iet.unipi.it</email>
; Tel.: +39-050-2217-549; Fax: +39-050-2217-600.</corresp>
</author-notes>
<pub-date pub-type="collection"><year>2012</year>
</pub-date>
<pub-date pub-type="epub"><day>07</day>
<month>11</month>
<year>2012</year>
</pub-date>
<volume>12</volume>
<issue>11</issue>
<fpage>15133</fpage>
<lpage>15158</lpage>
<history><date date-type="received"><day>19</day>
<month>9</month>
<year>2012</year>
</date>
<date date-type="rev-recd"><day>26</day>
<month>10</month>
<year>2012</year>
</date>
<date date-type="accepted"><day>30</day>
<month>10</month>
<year>2012</year>
</date>
</history>
<permissions><copyright-statement>© 2012 by the authors; licensee MDPI, Basel, Switzerland.</copyright-statement>
<copyright-year>2012</copyright-year>
<license><license-p><pmc-comment>CREATIVE COMMONS</pmc-comment>
This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution license (<ext-link ext-link-type="uri" xlink:href="http://creativecommons.org/licenses/by/3.0/">http://creativecommons.org/licenses/by/3.0/</ext-link>
).</license-p>
</license>
</permissions>
<abstract><p>In this paper we describe a security suite for Underwater Acoustic Sensor Networks comprising both fixed and mobile nodes. The security suite is composed of a secure routing protocol and a set of cryptographic primitives aimed at protecting the confidentiality and the integrity of underwater communication while taking into account the unique characteristics and constraints of the acoustic channel. By means of experiments and simulations based on real data, we show that the suite is suitable for an underwater networking environment as it introduces limited, and sometimes negligible, communication and power consumption overhead.</p>
</abstract>
<kwd-group><kwd>underwater acoustic sensor network</kwd>
<kwd>security</kwd>
<kwd>confidentiality</kwd>
<kwd>integrity</kwd>
<kwd>secure routing</kwd>
</kwd-group>
</article-meta>
</front>
<body><sec><label>1.</label>
<title>Introduction</title>
<p>Underwater Acoustic Sensor Networks (UASNs) are constituted by underwater sensor nodes and autonomous underwater vehicles (AUVs) interconnected by a wireless acoustic underwater communication network. UASNs can be used for many purposes including ocean sampling, environment monitoring, undersea explorations, distributed tactical surveillance and disaster prevention [<xref ref-type="bibr" rid="b1-sensors-12-15133">1</xref>
].</p>
<p>Co-ordination and sharing of information among sensor nodes and AUVs require secure communication [<xref ref-type="bibr" rid="b2-sensors-12-15133">2</xref>
]. Since the acoustic channel is an open medium, an attacker conveniently equipped by an acoustic modem can easily eavesdrop on the messages traversing the network. This could be very dangerous, for example, in distributed tactical surveillance applications where messages must be secret. Furthermore, the attacker can also modify or inject fake messages so compromising the integrity of the system at both the application and the network layer. The level of damage that may ensue depends on the specific case. However, it may include an alteration of the positives/negatives rate, forms of denial of service deriving from the violation of the integrity of the routing service [<xref ref-type="bibr" rid="b3-sensors-12-15133">3</xref>
], and even the loss or the damage of AUVs and sensor nodes. All these considerations show the urgency of establishing secure channels among underwater nodes.</p>
<p>The unique characteristics of the underwater acoustic channel, and the differences between UASNs and their ground counterpart, namely Wireless Sensor Networks (WSNs) [<xref ref-type="bibr" rid="b4-sensors-12-15133">4</xref>
], require the development of efficient security mechanisms. Radio waves do not propagate well underwater due to the high energy absorption of water. Therefore, underwater communication is based on acoustic waves that are characterised by large propagation delays. The propagation speed of sound in water is typically 1,500 m/s, five orders of magnitude lower than light speed. In addition, acoustic links have low bandwidth and low quality due to the chemical-physical properties of the water medium such as temperature, salinity, density and spatio-temporal variations. Furthermore, underwater hardware is more expensive than WSNs nodes, and thus underwater nodes are sparsely deployed. It follows that underwater communication have more stringent power requirements than terrestrial systems because acoustic communication are more energy expensive, distances between underwater nodes are greater and thus higher power is required to ensure coverage [<xref ref-type="bibr" rid="b1-sensors-12-15133">1</xref>
].</p>
<p>In this paper we present the secure communication suite for UASNs we have designed and experimented within the European project called “Underwater Acoustic Network” (UAN) [<xref ref-type="bibr" rid="b5-sensors-12-15133">5</xref>
]. We have considered a UASN composed of both AUVs and fixed underwater sensor nodes that cooperate towards the same application. Nodes may move as well as dynamically join and leave the system. A node joins the system when its mission starts and leaves when its missions finishes. A node may also be forced to leave when suspected of being compromised. The reference application scenario was a distributed surveillance system. The secure communication suite is composed of two integrated components—a <italic>secure routing protocol</italic>
and a set of <italic>cryptographic primitives</italic>
(cipher, digest, and re-keying)—and aims at protecting confidentiality and integrity of the application and network control messages while taking into account the peculiarities of the underwater acoustic medium.</p>
<p>The paper provides the following novel contributions. First of all, the paper presents a practical and efficient solution to secure communication in UASNs. The proposed suite (i) protects end-to-end confidentiality and integrity; (ii) supports both the one-to-one and one-to-many communication paradigm; (iii) allows secure reconfiguration due to nodes mobility, joining, and leaving. The resulting suite introduces limited communication overhead and negligible energy consumption. We show that these claims are well founded by means of sea trials and simulations based on real data. To the best of our knowledge, this is the first secure communication suite that has been implemented and tested in the field.</p>
<p>Second, by means of experiments and real data, the paper proves that the resulting security suite is indeed suitable for an underwater acoustic networking environment. We believe that reporting design choices and field performance is valuable in itself because it may allow the research community to orient towards either refinements of the proposed approach or different approaches altogether, however with the long-term objective of achieving operational implementations of secure underwater acoustic networks.</p>
<p>The paper is organized as follows. Section 2 discusses related work. Section 3 and Section 4 describe the system and threat model, respectively. Section 5 describes the cryptographic suite whereas Section 6 describes the secure routing. Section 7 presents performance evaluation carried out by means of experiments in the field and simulations with real data. Finally, Section 8 reports our final considerations.</p>
</sec>
<sec><label>2.</label>
<title>Related Work</title>
<p>The problem of secure underwater acoustic communication is quite a new research field [<xref ref-type="bibr" rid="b1-sensors-12-15133">1</xref>
,<xref ref-type="bibr" rid="b2-sensors-12-15133">2</xref>
]. Domingo presents a survey of security issues, and possible countermeasures. Similarly, [<xref ref-type="bibr" rid="b6-sensors-12-15133">6</xref>
,<xref ref-type="bibr" rid="b7-sensors-12-15133">7</xref>
] analyze the security and threats of UASN. Dong <italic>et al.</italic>
make a taxonomy of the attacks against a UASN [<xref ref-type="bibr" rid="b8-sensors-12-15133">8</xref>
]. They classify the attacks into three categories: (a) physical attacks against nodes; (b) attacks against the network; and finally, (c) attacks against the protocols. Although they give guidelines to contrast such attacks, they do not propose any concrete solution.</p>
<p>Some solutions to specific security problems have been presented. Dong <italic>et al.</italic>
have proposed mechanisms for network reconfiguration when one or more nodes get destroyed [<xref ref-type="bibr" rid="b9-sensors-12-15133">9</xref>
,<xref ref-type="bibr" rid="b10-sensors-12-15133">10</xref>
]. Solutions against wormholes have been presented in [<xref ref-type="bibr" rid="b11-sensors-12-15133">11</xref>
,<xref ref-type="bibr" rid="b12-sensors-12-15133">12</xref>
]. Zuba <italic>et al.</italic>
study the effects of denial-of-service jamming attacks on UANs using real-world field tests by building their own hardware jammer [<xref ref-type="bibr" rid="b13-sensors-12-15133">13</xref>
]. They show that underwater acoustic networks can be easily jammed by carefully using timed attacks, which are energy efficient. Finally, Liu and Zhang have proposed a key establishment scheme that is based on the channel characteristics [<xref ref-type="bibr" rid="b14-sensors-12-15133">14</xref>
] whereas Liu <italic>et al.</italic>
have proposed a key distribution scheme based on the mobility model of underwater mobile sensors [<xref ref-type="bibr" rid="b15-sensors-12-15133">15</xref>
].</p>
<p>In this paper, we face with an orthogonal problem, namely secure end-to-end communication. We present a secure communication suite that: (i) protects end-to-end communication; (ii) supports both the one-to-one and one-to-many communication model; (iii) allows secure network reconfiguration due to nodes mobility, joining and leaving; and finally, (iv) has been evaluated in the real-world field. To the best of our knowledge, no such a contribution has been given so far. Cong <italic>et al.</italic>
have proposed a cross-layer scheme for secure communication but they do not go further than illustrating the basic ideas underlying their proposal [<xref ref-type="bibr" rid="b16-sensors-12-15133">16</xref>
]. In particular, they do not provide an implementation and a performance evaluation.</p>
<p>The communication suite is composed of two components, a set of cryptographic primitives and a secure routing protocol. As to the cryptographic primitives, they have been initially proposed in [<xref ref-type="bibr" rid="b17-sensors-12-15133">17</xref>
]. Then, in [<xref ref-type="bibr" rid="b18-sensors-12-15133">18</xref>
] we have employed them to protect application-level communications. Here, we present the integration of the primitives with the routing protocol and show that they are adequate at the network-layer too. As to the secure routing protocol, the basic ideas behind it have been sketched in [<xref ref-type="bibr" rid="b19-sensors-12-15133">19</xref>
]. Here, we provide a complete and detailed description of the protocol as well as an evaluation of its performance.</p>
</sec>
<sec><label>3.</label>
<title>System Model</title>
<p>We consider an underwater surveillance system aimed at protecting a critical asset by means of an underwater acoustic network. The system is composed of a set of networked underwater nodes, each equipped with sensing, computing and acoustic communication facilities. Every underwater node has computational resources and power saving capabilities comparable to those of a low-budget personal computer (e.g., a PC/104 embedded computer) and it is able to run a commodity operating system such as Windows XP or Linux. Nodes are battery operated and thus have limited energy resources.</p>
<p>Every node is equipped with a number of sensors that allow it to both sense the state of surrounding waters and detect the presence of targets in the neighbourhood. Of course, a node may only achieve a local partial view of the state of the system. For this reason, several nodes are deployed around the critical asset and each of them reports the sensed data to a Command and Control Center (C3) station. Such a station collects sensed data from underwater nodes, so achieving a global view of the system (e.g., it performs the intrusion detection algorithm).</p>
<p>Underwater nodes may be both fixed and mobile. Mobile nodes are <italic>autonomous underwater vehicles</italic>
(AUVs). AUVs are crucial components in the surveillance system. Intuitively, the surveillance system strives to cover the largest connected detection area. Due to the changing sea conditions, fixed nodes alone would be hardly able to guarantee this requirement all the time. For this reason, the system employs AUVs that dynamically change their position in order to fulfill the requirement. AUVs move to target locations in response to specific commands from the C3 station. Upon reaching their respective target locations, AUVs dynamically and cooperatively adjust their positions according to the changed sea conditions in order to maintain communication and detection connectivity. We do not provide any greater details about the application and the co-operation algorithm because here we are interested in the communication model the application subsumes. The communication model will be the starting point for specifying the requirements of secure communication. More details about the application and the cooperation algorithms can be found in [<xref ref-type="bibr" rid="b20-sensors-12-15133">20</xref>
].</p>
<p>The above system model indicates two different communication paradigms that we need to support: (a) <italic>one-to-one</italic>
communication between C3 and a single underwater node; and (b) <italic>one-to-many</italic>
communication among nodes. Given the peculiarities of an underwater communication [<xref ref-type="bibr" rid="b1-sensors-12-15133">1</xref>
], we support these paradigms by means of a network organized as shown in <xref ref-type="fig" rid="f1-sensors-12-15133">Figure 1</xref>
.</p>
<p>The <italic>gateway</italic>
(GW) is a node located close to the asset and capable of both radio and acoustic communication. The gateway is not energy constrained as it receives power from the asset through a power cable. In the one-to-one communication paradigm, the gateway GW relays messages between underwater nodes and the C3 station (see <xref ref-type="fig" rid="f2-sensors-12-15133">Figure 2(a)</xref>
).</p>
<p>As to the one-to-many communication, in principle a node could directly broadcast a message to the destinations. However, as the power necessary to send a message decays with a power of distance greater than two [<xref ref-type="bibr" rid="b1-sensors-12-15133">1</xref>
,<xref ref-type="bibr" rid="b21-sensors-12-15133">21</xref>
], then the power necessary to reach all destinations would be too large, and nodes would drain their battery very quickly. For this reason, with reference to <xref ref-type="fig" rid="f2-sensors-12-15133">Figure 2(b)</xref>
, when a node wishes to broadcast a message, it actually sends the message to the GW (message 1) which actually broadcasts it (message 2). The gateway is not power constrained and thus it can use all the necessary power.</p>
</sec>
<sec><label>4.</label>
<title>Threat Model</title>
<p>An underwater acoustic network is subjected to several threats and possible attacks [<xref ref-type="bibr" rid="b16-sensors-12-15133">16</xref>
]. An adversary equipped with an acoustic modem can eavesdrop on messages as well as modify and inject fake messages so endangering the confidentiality and integrity of application messages.</p>
<p>In a surveillance system, integrity is as important as confidentiality. Actually, an adversary that is able to spoof a node and thus impersonate it can then inject fake messages. Fake messages may carry wrong measurements as well as wrong commands for mobile nodes. Wrong measurements may lead the surveillance system to return wrong results in terms of false positives/negatives. Wrong commands may cause the network to disrupt or even translate into a safety issue with possible damages to devices themselves.</p>
<p>In order to protect integrity and confidentiality, we assume that underwater communications are enciphered. At the application level, every node <italic>u</italic>
shares a secret symmetric <italic>end-to-end</italic>
key, <italic>e<sub>u</sub>
</italic>
with the gateway GW for one-to-one communication. Node <italic>u</italic>
uses the key <italic>e<sub>u</sub>
</italic>
to encrypt unicast application message addressed to GW, and to decrypt unicast messages received from GW.</p>
<p>In addition, in order to support one-to-many communication, the gateway GW and the mobile nodes are organized as a <italic>group</italic>
and, as such, they share a secret symmetric <italic>group key g</italic>
. Every group member uses <italic>g</italic>
to encrypt/decrypt application messages before broadcasting/receiving them into/from the group.</p>
<p>An adversary may also attack availability. Denial of Service (DoS) is a severe threat in an underwater acoustic network, even more severe than in traditional networks, due to the intrinsic limitations of the acoustic channel [<xref ref-type="bibr" rid="b21-sensors-12-15133">21</xref>
]. In the UAN project, we have contrasted DoS at multiple different layers. In this paper we mainly focus on DoS that may derive from attacks to network integrity [<xref ref-type="bibr" rid="b3-sensors-12-15133">3</xref>
]. We come back to this point later in Section 6 for more details. However, here, we would like to spend just a few intuitions about the countermeasures against DoS we have adopted at the application level. These countermeasures are complementary to those applied at the network layer. The cooperative algorithm that allows UAVs to maintain the largest sensing area is intrinsically reactive against DoS due to the <italic>emergent behaviour</italic>
approach on which it is based [<xref ref-type="bibr" rid="b22-sensors-12-15133">22</xref>
,<xref ref-type="bibr" rid="b23-sensors-12-15133">23</xref>
]. In brief, whenever an adversary succeeds in disrupting communication among vehicles, the simple rules that drive vehicles motion make them move closer to the asset in order to ensure protection regardless what the other agents are doing. As a result, a DoS attack effectively degrades the performance of the cooperation, but it cannot prevent continuing the surveillance mission with a limited number of cooperating nodes, or even with all the nodes acting individually. A detailed description of the algorithm can be found in [<xref ref-type="bibr" rid="b20-sensors-12-15133">20</xref>
]. Furthermore, from a practical standpoint, if the DoS attack persists, an underwater node may take an extreme measure, namely surface and communicate with a land station using standard radio communication technologies. We have used this approach in a surveillance system but it can be generalized to other underwater application scenarios.</p>
</sec>
<sec><label>5.</label>
<title>The Cryptographic Suite</title>
<p>Supporting secure communication in an underwater acoustic network is challenging due to the severe limitations of the networking environment in terms of very high message propagation delay, very low bandwidth, and high energy consumption for communication [<xref ref-type="bibr" rid="b21-sensors-12-15133">21</xref>
].</p>
<p>Cryptography is the primary means to support confidentiality and integrity. Cryptographic primitives tend to cause the <italic>ciphertext expansion</italic>
phenomenon. Actually, the message padding as well as modification identification codes (MICs) and message authentication codes (MACs) make the message length to increase after applying cryptography [<xref ref-type="bibr" rid="b24-sensors-12-15133">24</xref>
]. It follows that message expansion becomes responsible of a longer transmission delay and an increased energy consumption. Depending on the cryptographic primitive, such an additional communication overhead due to security may be comparable to, if not even greater than, the overhead related to transmitting the payload itself. It follows that a properly designed cryptographic suite for an underwater acoustic network has to avoid, or at least mitigate, the message expansion phenomenon.</p>
<p>Furthermore, underwater nodes are generally deployed in unattended, possible hostile, environments [<xref ref-type="bibr" rid="b25-sensors-12-15133">25</xref>
]. Generally, cost reasons prevent us to deploy tamper-resistant devices. For this reason, we cannot exclude that an adversary may be able to compromise an underwater node and alter its behaviour. Detecting compromised nodes much depends on detecting anomalies in expected communication and movement patterns [<xref ref-type="bibr" rid="b26-sensors-12-15133">26</xref>
], which are highly application-dependent. However, reactive measures to remove the compromised node from the system once detected should be considered by design. Concerning this, the cryptographic suite provides rekeying as a reactive measure to remove, at least logically a compromised device from the network. Actually, by revoking the keys held by a compromised device we revoke its ability to send and receive messages. However, in some situations revoking keys can be insufficient. Indeed the intruder could still be able to flood or jam the network. In these cases, physical removal becomes essential. However, even in situations where physical revocation of a compromised node is necessary, the ability of rekeying the system is indispensable. Actually, although the misbehaving device will be physically removed, it has been under the adversary control for a while and thus any secret therein contained (e.g., passwords and cryptographic keys) cannot be trusted anymore and have to be considered compromised.</p>
<p>In Sections 5.1 and 5.2 we describe our solutions aimed at avoiding message expansion in secure message communication. In Section 5.3 we describe an efficient and scalable rekeying service.</p>
<sec><label>5.1.</label>
<title>Confidentiality</title>
<p>Confidentiality of messages is achieved by encrypting them with a block cipher. Encryption is achieved by splitting cleartext in blocks of fixed, predefined bit-length and then encrypting every block. In the most general case, cleartext length is not multiple of the block length. Thus padding is necessary. However, padding has the negative effect that the ciphertext may result up to one block longer than the corresponding cleartext. This effect is an instance of the ciphertext expansion phenomenon.</p>
<p>While ciphertext expansion is negligible in a traditional network, it becomes relevant in wireless sensor networks and, in particular, underwater acoustic networks. In these networks, communication and energy limitations require to keep a message size small and ciphertext expansion may introduce an overhead that is not negligible anymore. For instance, in the AES encryption algorithm the block size is 128 bits. As the message size in the UAN project is, on average, around 720 bits, then the message expansion due to padding would be around 18%.</p>
<p>In order to completely avoid the ciphertext expansion problem, we use the CipherText Stealing (CTS) technique that alters the processing of the last two blocks of plaintext, resulting in a reordered transmission of the last two blocks of ciphertext and no ciphertext expansion [<xref ref-type="bibr" rid="b27-sensors-12-15133">27</xref>
].</p>
</sec>
<sec><label>5.2.</label>
<title>Integrity</title>
<p>Encryption without authentication is insecure [<xref ref-type="bibr" rid="b24-sensors-12-15133">24</xref>
]. For example, an adversary may flip bits in unauthenticated ciphertext and cause predictable changes in the plaintext that receivers are not able to detect. To address this vulnerability, the system always authenticates messages. Security of hash functions is directly related to the length of the digest. However, as a digest is appended to the message, it becomes another source of message expansion and consequent communication overhead. For instance, the size of a digest produced by SHA-256 is 256 bits, which causes an additional overhead that amounts to around 35% of an average UAN message.</p>
<p>UAN features a trade-off between security and performance by using 4 bytes digests resulting from truncating the real hash function value. Using, such a short hash size, the overhead becomes around 4.4% of the UAN average message, which is almost negligible. Furthermore, using such a short hash function value is not detrimental to security [<xref ref-type="bibr" rid="b28-sensors-12-15133">28</xref>
]. An adversary has 1 in 2<sup>32</sup>
chances to blindly forge a digest. If an adversary repeatedly tries to forge it, he/she needs at maximum 2<sup>31</sup>
trials. However, the adversary cannot perform trials off-line. This means that the adversary has to validate a given forgery only by sending it to an authorized receiver. This implies that the adversary has to send 2<sup>31</sup>
messages in order to successfully forge a single malicious message. In a conventional network, this number of trials is not large enough. However, in an underwater acoustic network this may provide an adequate level of security. An adversary can try to flood the network with forgeries, but on a 500 bps channel with 184-bit messages, he/she can only send about 2.71 attempts for second. Thus, sending 2<sup>31</sup>
messages requires around 306 months, <italic>i.e.</italic>
, about 25 years. Battery-operated vehicles have not enough energy to receive that many messages. Furthermore, the integrity attack would translate into a denial of service attack since the adversary needs to occupy the acoustic channel for a long time. Fortunately, it is feasible to detect when such an attack is underway. UAN uses a simple heuristic: vehicles could signal the base station when the rate of digest/MAC failures exceeds some predetermined threshold.</p>
</sec>
<sec><label>5.3.</label>
<title>Group Key Management</title>
<p>Each time a node leaves the system, the GW generates and distributes a new group key <italic>g</italic>
. This is done to avoid that an old node is able to read new messages. As to rekeying protocol, we chose S2RP, a secure and scalable rekeying protocol for resource-constrained devices [<xref ref-type="bibr" rid="b29-sensors-12-15133">29</xref>
,<xref ref-type="bibr" rid="b30-sensors-12-15133">30</xref>
]. S2RP is particularly suitable for UAN for two reasons. First of all, S2RP provides a very efficient proof of key authenticity. Actually, S2RP verifies the authenticity of a key by computing a digest of it. So, verification is very computing efficient and does not require any additional information, e.g., MACs or digital signatures, which would cause a great message expansion. Secondly, S2RP requires a number of rekeying messages that is logarithmic in the number of nodes so making the key distribution phase highly scalable.</p>
<p>In short, the key authentication mechanism levers on <italic>key-chains</italic>
, a technique based on Lamport's one-time passwords. A key-chain is a set of symmetric keys so that each key is the hash pre-image of the previous one (see <xref ref-type="fig" rid="f3-sensors-12-15133">Figure 3</xref>
). Hence, given a key <italic>k</italic>
<sup>(</sup>
<italic><sup>i</sup>
</italic>
<sup>)</sup>
in the key-chain, anybody can compute all the previous keys <italic>k</italic>
<sup>(</sup>
<italic><sup>j</sup>
</italic>
<sup>)</sup>
, <italic>j</italic>
≤ <italic>i</italic>
, however nobody, but the key-chain creator, can compute any of the next keys <italic>k</italic>
<sup>(</sup>
<italic><sup>j</sup>
</italic>
<sup>)</sup>
, <italic>j</italic>
> <italic>i</italic>
. Keys are revealed in the reversed order with respect to creation order. Therefore, given an authenticated key in the key-chain, anybody can authenticate the next revealed keys by simply applying a hash function. For example, if <italic>k</italic>
<sup>(</sup>
<italic><sup>i</sup>
</italic>
<sup>)</sup>
is an authenticated key, than anyone can verify the authenticity of <italic>k</italic>
<sup>(</sup>
<italic><sup>i</sup>
</italic>
<sup>+1)</sup>
by verifying that <italic>k</italic>
<sup>(</sup>
<italic><sup>i</sup>
</italic>
<sup>)</sup>
= <italic>h</italic>
(<italic>k</italic>
<sup>(</sup>
<italic><sup>i</sup>
</italic>
<sup>+1)</sup>
). We call <italic>current key</italic>
of a key-chain the last revealed key of the key-chain and <italic>next key</italic>
the hash pre-image of that key. We denote them by <italic>k</italic>
and <italic>k</italic>
<sup>+</sup>
, respectively. Notice that <italic>k</italic>
= <italic>h</italic>
(<italic>k</italic>
<sup>+</sup>
).</p>
<p>To reduce the communication overhead, the gateway GW maintains a logical key tree (see <xref ref-type="fig" rid="f4-sensors-12-15133">Figure 4</xref>
) where each internal node is associated to a key-chain and each leaf is associated with a node's node-key (<italic>i.e.</italic>
, the secret key that the node shares with GW). We denote by <italic>k<sub>i</sub>
</italic>
the current key of the hash-chain associated with the internal tree node <italic>i</italic>
. Keys in the hash chain are only used in the rekeying process and thus are called <italic>key encryption keys</italic>
(KEKs).</p>
<p>Each node maintains a <italic>key-ring</italic>
that contains every KEK <italic>k<sub>i</sub>
</italic>
such that the sub-tree rooted at node <italic>i</italic>
contains the leaf associated with the node-key. Hence, with reference to <xref ref-type="fig" rid="f4-sensors-12-15133">Figure 4</xref>
, the <italic>key-ring</italic>
of node <italic>υ</italic>
<sub>4</sub>
is {<italic>k</italic>
<sub>1</sub>
, <italic>k</italic>
<sub>2</sub>
, <italic>k</italic>
<sub>5</sub>
}. As it turns out, key <italic>k</italic>
<sub>1</sub>
, associated to the key tree root, is shared by all nodes and thus can act as the group-key, <italic>i.e.</italic>
, <italic>g</italic>
≡ <italic>k</italic>
<sub>1</sub>
.</p>
<p>In order to have an idea of how the protocol works, let us consider the logical key tree in <xref ref-type="fig" rid="f4-sensors-12-15133">Figure 4</xref>
. Let us now assume that node <italic>υ</italic>
<sub>4</sub>
leaves the group. All keys in its key ring are considered compromised and GW has to broadcast the respective next keys
<inline-formula><mml:math id="mm1"><mml:mrow><mml:msubsup><mml:mi>k</mml:mi>
<mml:mn>1</mml:mn>
<mml:mo>+</mml:mo>
</mml:msubsup>
</mml:mrow>
</mml:math>
</inline-formula>
,
<inline-formula><mml:math id="mm2"><mml:mrow><mml:msubsup><mml:mi>k</mml:mi>
<mml:mn>2</mml:mn>
<mml:mo>+</mml:mo>
</mml:msubsup>
</mml:mrow>
</mml:math>
</inline-formula>
,
<inline-formula><mml:math id="mm3"><mml:mrow><mml:msubsup><mml:mi>k</mml:mi>
<mml:mn>5</mml:mn>
<mml:mo>+</mml:mo>
</mml:msubsup>
</mml:mrow>
</mml:math>
</inline-formula>
by means of the following rekeying messages:
<list list-type="order"><list-item><p>GW → <italic>υ</italic>
<sub>3</sub>
:
<inline-formula><mml:math id="mm4"><mml:mrow><mml:msub><mml:mi>E</mml:mi>
<mml:mrow><mml:msub><mml:mi>e</mml:mi>
<mml:mrow><mml:msub><mml:mi>υ</mml:mi>
<mml:mn>3</mml:mn>
</mml:msub>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:msub>
<mml:mo stretchy="false">(</mml:mo>
<mml:msubsup><mml:mi>k</mml:mi>
<mml:mn>5</mml:mn>
<mml:mo>+</mml:mo>
</mml:msubsup>
<mml:mo stretchy="false">)</mml:mo>
</mml:mrow>
</mml:math>
</inline-formula>
</p>
</list-item>
<list-item><p>GW → <italic>υ</italic>
<sub>3</sub>
:
<inline-formula><mml:math id="mm5"><mml:mrow><mml:msub><mml:mi>E</mml:mi>
<mml:mrow><mml:msubsup><mml:mi>k</mml:mi>
<mml:mn>5</mml:mn>
<mml:mo>+</mml:mo>
</mml:msubsup>
</mml:mrow>
</mml:msub>
<mml:mo stretchy="false">(</mml:mo>
<mml:msubsup><mml:mi>k</mml:mi>
<mml:mn>2</mml:mn>
<mml:mo>+</mml:mo>
</mml:msubsup>
<mml:mo stretchy="false">)</mml:mo>
</mml:mrow>
</mml:math>
</inline-formula>
</p>
</list-item>
<list-item><p>GW → {<italic>υ</italic>
<sub>1</sub>
, <italic>υ</italic>
<sub>2</sub>
}:
<inline-formula><mml:math id="mm6"><mml:mrow><mml:msub><mml:mi>E</mml:mi>
<mml:mrow><mml:msub><mml:mi>k</mml:mi>
<mml:mn>4</mml:mn>
</mml:msub>
</mml:mrow>
</mml:msub>
<mml:mo stretchy="false">(</mml:mo>
<mml:msubsup><mml:mi>k</mml:mi>
<mml:mn>2</mml:mn>
<mml:mo>+</mml:mo>
</mml:msubsup>
<mml:mo stretchy="false">)</mml:mo>
</mml:mrow>
</mml:math>
</inline-formula>
</p>
</list-item>
<list-item><p>GW → {<italic>υ</italic>
<sub>1</sub>
, <italic>υ</italic>
<sub>2</sub>
, <italic>υ</italic>
<sub>3</sub>
}:
<inline-formula><mml:math id="mm7"><mml:mrow><mml:msub><mml:mi>E</mml:mi>
<mml:mrow><mml:msub><mml:mi>k</mml:mi>
<mml:mrow><mml:mn>2</mml:mn>
<mml:mo>+</mml:mo>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:msub>
<mml:mo stretchy="false">(</mml:mo>
<mml:msubsup><mml:mi>k</mml:mi>
<mml:mn>1</mml:mn>
<mml:mo>+</mml:mo>
</mml:msubsup>
<mml:mo stretchy="false">)</mml:mo>
</mml:mrow>
</mml:math>
</inline-formula>
</p>
</list-item>
<list-item><p>GW → {<italic>υ</italic>
<sub>5</sub>
, <italic>υ</italic>
<sub>6</sub>
, <italic>υ</italic>
<sub>7</sub>
, <italic>υ</italic>
<sub>8</sub>
}:
<inline-formula><mml:math id="mm8"><mml:mrow><mml:msub><mml:mi>E</mml:mi>
<mml:mrow><mml:msub><mml:mi>k</mml:mi>
<mml:mn>3</mml:mn>
</mml:msub>
</mml:mrow>
</mml:msub>
<mml:mo stretchy="false">(</mml:mo>
<mml:msubsup><mml:mi>k</mml:mi>
<mml:mn>1</mml:mn>
<mml:mo>+</mml:mo>
</mml:msubsup>
<mml:mo stretchy="false">)</mml:mo>
</mml:mrow>
</mml:math>
</inline-formula>
</p>
</list-item>
</list>
</p>
<p>Upon receiving a rekeying message, after it has been properly decrypted, the authenticity of the next key therein contained is verified by computing its hash and comparing the result to the corresponding current key. For instance, upon receiving rekeying message 5, <italic>n</italic>
<sub>6</sub>
decrypts the message by means of <italic>k</italic>
<sub>3</sub>
and verifies the authenticity of
<inline-formula><mml:math id="mm9"><mml:mrow><mml:msubsup><mml:mi>k</mml:mi>
<mml:mn>1</mml:mn>
<mml:mo>+</mml:mo>
</mml:msubsup>
</mml:mrow>
</mml:math>
</inline-formula>
by ascertaining that
<inline-formula><mml:math id="mm10"><mml:mrow><mml:msub><mml:mi>k</mml:mi>
<mml:mn>1</mml:mn>
</mml:msub>
<mml:mo>=</mml:mo>
<mml:mi>h</mml:mi>
<mml:mo stretchy="false">(</mml:mo>
<mml:msubsup><mml:mi>k</mml:mi>
<mml:mn>1</mml:mn>
<mml:mo>+</mml:mo>
</mml:msubsup>
<mml:mo stretchy="false">)</mml:mo>
</mml:mrow>
</mml:math>
</inline-formula>
. As it turns out the rekeying protocol requires <italic>O</italic>
(log <italic>n</italic>
) rekeying messages, where <italic>n</italic>
is the number of nodes. Furthermore, given the key-chain authentication mechanism, every rekeying message needs to carry only the next key (in its encrypted format). No additional information proving key authenticity is thus required. Notice that this is a great advantage in terms of communication overhead with respect to using digital signatures, for example. To fix ideas, let us suppose that group keys are 128-bit long and we use ECC-180 digital signature to authenticate them. ECC-180 is nowadays considered as secure as RSA-1024. In ECC-180 a digital signature is 360 bits and thus a rekeying message would be 488 bits, <italic>i.e.</italic>
, 3.8125 times longer than in the approach proposed here.</p>
</sec>
</sec>
<sec><label>6.</label>
<title>On Control Messages Protection</title>
<p>So far, our focus has been on protecting the integrity and confidentiality of application messages, namely, messages whose payload contains data sent by the application layer of the network, such as sensor readings or commands to AUVs. However, unless the surveillance communication sub-system fits within a single acoustic broadcast domain, a multi-hop, ad-hoc acoustic network is necessary. In such a case, we have to consider integrity and confidentiality of <italic>control messages</italic>
too, namely messages whose payload contains data used to maintain the network services. These include, for instance, routing discovery messages and routing maintenance messages. All of these control messages are of fundamental importance for availability. However, contrary to confidentiality and integrity, we can not assume end-to-end security for control messages because the network is by definition a distributed protocol.</p>
<p>Disrupting the functionality of the routing protocols compromises the availability of the network and services running on the network. Attacks against routing protocols include attempts to create routing loops or black holes (when attacker claims to be a short distance to all destinations and then selectively forwards payload traffic). Therefore, the same principles of service integrity and service confidentiality apply to control messages. To provide a secure communication infrastructure, control messages need to have authentication and replay protection. Therefore, these messages need to use message integrity codes. Also, to prevent an outsider from identifying the type of control messages being transmitted, we should have these messages encrypted.</p>
<p>In the UAN project we have used FLOOD, a routing protocol that has been designed for, and tested in, an underwater acoustic networks [<xref ref-type="bibr" rid="b31-sensors-12-15133">31</xref>
]. Unfortunately, FLOOD does not provide any mechanism to protect the confidentiality and integrity of control messages and this makes FLOOD prone to attacks. For this reason, we have designed and implemented <italic>secure FLOOD</italic>
(SeFLOOD), a secure version of FLOOD where every control message is protected by means of the cryptographic suite described in Section 5. In order to protect routing control messages we need link layer keys shared by pairs of neighbouring nodes. As these keys are meant to protect routing control messages, they have to be established before the routing protocol starts.</p>
<p>In Section 6.1 we provide a brief description of FLOOD. By way of example, in Section 6.2 we highlight FLOOD vulnerabilities and describe a spoofing attack against control message integrity that translates into Denial of Service (DoS). Finally, in Section 6.3 we describe SeFLOOD which incorporates the establishment of link-layer shared keys.</p>
<sec><label>6.1.</label>
<title>FLOOD: The Routing Protocol for UAN</title>
<p>FLOOD is a routing protocol for UAN. It is composed of three phases: the <italic>network discovery</italic>
phase, the <italic>data routing</italic>
phase and the <italic>network reconfiguration</italic>
phase. In the <italic>network discovery</italic>
phase, nodes discover one another in order to build the routing tables. In practice, each node reports to the GW all the neighbors it has discovered and their relative information (e.g., link quality, water conditions). Once received all the information, the GW builds the routing tables, one for each node, by applying the Dijkstra algorithm [<xref ref-type="bibr" rid="b32-sensors-12-15133">32</xref>
] and distributes them to the corresponding nodes. At this point the network discovery phase ends and the <italic>data routing</italic>
phase begins. In this phase, each node routes messages according to the routing tables received from the GW. Upon a node's leaving or joining the network, a <italic>network reconfiguration</italic>
phase is performed.</p>
<p>As to the security of the control messages and thus the integrity of the network infrastructure, the network discovery phase and the network reconfiguration phase are particularly relevant. For this reason, we briefly review them in Sections 6.1.1 and 6.1.2 as far as their salient features related to security are concerned. For a detailed description of FLOOD, readers may refer to [<xref ref-type="bibr" rid="b31-sensors-12-15133">31</xref>
].</p>
<sec><label>6.1.1.</label>
<title>The Network Discovery Phase</title>
<p>The FLOOD Network Discovery Phase is based on the <italic>flooding</italic>
principle. The protocol is based on the <italic>flooding mechanism</italic>
. Upon receiving a control discovery message, a node re-broadcasts it unless the node has not already done it. To fix ideas, consider <xref ref-type="fig" rid="f5-sensors-12-15133">Figure 5</xref>
which shows an execution instance of the FLOOD protocol. In the figure, we show that the network is composed of three nodes. Furthermore, assume that the transmission range of node <italic>u</italic>
<sub>1</sub>
(the gateway) only covers node <italic>u</italic>
<sub>2</sub>
, whereas node <italic>u</italic>
<sub>2</sub>
is able to reach both <italic>u</italic>
<sub>1</sub>
and <italic>u</italic>
<sub>3</sub>
, and, finally, node <italic>u</italic>
<sub>3</sub>
is able to reach only <italic>u</italic>
<sub>2</sub>
.</p>
<p>The protocol is initiated by the GW which broadcasts a
<preformat position="float" xml:space="preserve"><monospace>HELLO</monospace>
</preformat>
(<italic>u</italic>
<sub>1</sub>
), including its identifier and the time <italic>t<sub>i</sub>
</italic>
at which the message is sent. Upon receiving the hello message, the node <italic>u</italic>
<sub>2</sub>
adds to the message its identifier and other information, including the quality of the link (e.g., signal attenuation). Then <italic>u</italic>
<sub>2</sub>
relays the message
<preformat position="float" xml:space="preserve"><monospace>HELLO</monospace>
</preformat>
(<italic>u</italic>
<sub>1</sub>
,<italic>u</italic>
<sub>2</sub>
) by broadcasting it after a randomized delay. When <italic>u</italic>
<sub>1</sub>
receives the message, it re-broadcasts it. When <italic>u</italic>
<sub>2</sub>
receives the new message, it sends to <italic>u</italic>
<sub>1</sub>
a
<preformat position="float" xml:space="preserve"><monospace>REPORT</monospace>
</preformat>
(<italic>u</italic>
<sub>1</sub>
,<italic>u</italic>
<sub>2</sub>
) unicast message. The GW acknowledges <italic>u</italic>
<sub>2</sub>
by sending it a
<preformat position="float" xml:space="preserve"><monospace>ACK</monospace>
</preformat>
(<italic>u</italic>
<sub>1</sub>
,<italic>u</italic>
<sub>2</sub>
) unicast message. With the ack message, the protocol between <italic>u</italic>
<sub>1</sub>
and <italic>u</italic>
<sub>2</sub>
is completed. However, also the node <italic>u</italic>
<sub>3</sub>
receives the
<preformat position="float" xml:space="preserve"><monospace>HELLO</monospace>
</preformat>
(<italic>u</italic>
<sub>1</sub>
,<italic>u</italic>
<sub>2</sub>
) message. Suppose that <italic>u</italic>
<sub>3</sub>
receives it after that <italic>u</italic>
<sub>2</sub>
receives
<preformat position="float" xml:space="preserve"><monospace>ACK</monospace>
</preformat>
(<italic>u</italic>
<sub>1</sub>
,<italic>u</italic>
<sub>2</sub>
). The node <italic>u</italic>
<sub>3</sub>
adds to the message its identifier and information about link quality. Then it broadcasts HELLO(<italic>u</italic>
<sub>1</sub>
,<italic>u</italic>
<sub>2</sub>
,<italic>u</italic>
<sub>3</sub>
). Upon receiving this message, the node <italic>u</italic>
<sub>2</sub>
re-broadcasts it. The message is received both by the GW <italic>u</italic>
<sub>1</sub>
and the node <italic>u</italic>
<sub>3</sub>
. Upon receiving the message, the node <italic>u</italic>
<sub>3</sub>
builds a report message
<preformat position="float" xml:space="preserve"><monospace>REPORT</monospace>
</preformat>
(<italic>u</italic>
<sub>1</sub>
,<italic>u</italic>
<sub>2</sub>
,<italic>u</italic>
<sub>3</sub>
). When <italic>u</italic>
<sub>2</sub>
receives the report message from <italic>u</italic>
<sub>3</sub>
, it sends it the
<preformat position="float" xml:space="preserve"><monospace>ACK</monospace>
</preformat>
(<italic>u</italic>
<sub>1</sub>
,<italic>u</italic>
<sub>2</sub>
,<italic>u</italic>
<sub>3</sub>
) unicast message so that the protocol between <italic>u</italic>
<sub>2</sub>
and <italic>u</italic>
<sub>3</sub>
is complete. When the GW receives the message
<preformat position="float" xml:space="preserve"><monospace>HELLO</monospace>
</preformat>
(<italic>u</italic>
<sub>1</sub>
,<italic>u</italic>
<sub>2</sub>
,<italic>u</italic>
<sub>3</sub>
) it re-broadcasts it. Upon receiving the message the node <italic>u</italic>
<sub>2</sub>
builds a report message REPORT(<italic>u</italic>
<sub>1</sub>
,<italic>u</italic>
<sub>2</sub>
,<italic>u</italic>
<sub>3</sub>
). When <italic>u</italic>
<sub>1</sub>
receives the report message from <italic>u</italic>
<sub>2</sub>
, it sends it the
<preformat position="float" xml:space="preserve"><monospace>ACK</monospace>
</preformat>
(<italic>u</italic>
<sub>1</sub>
,<italic>u</italic>
<sub>2</sub>
,<italic>u</italic>
<sub>3</sub>
) unicast message so that the protocol between <italic>u</italic>
<sub>1</sub>
and <italic>u</italic>
<sub>2</sub>
is complete.</p>
</sec>
<sec><label>6.1.2.</label>
<title>The Network Reconfiguration Phase</title>
<p>FLOOD allows the network to reconfigure, <italic>i.e.</italic>
, it allows an AUV to move from one part of the network to another. From a network management point of view, this operation requires to: (i) reconstruct the neighbourhood of both the detaching and re-attaching points; (ii) update the routing tables. FLOOD supports this reconfiguration phase under the following assumptions: (a) each mobile node knows when it is going to move and when it has reached its new location; (b) each mobile node does not send/receive messages while moving.</p>
<p>Before starting moving, a mobile node <italic>u<sub>m</sub>
</italic>
sends GW a
<preformat position="float" xml:space="preserve"><monospace>DEL</monospace>
</preformat>
(<italic>u<sub>m</sub>
</italic>
). Upon receiving the message, GW updates the routing tables accordingly. If some nodes become unreachable through the new routing table, GW triggers a new instance of the Network Discovery Phase. Otherwise, it can continue the Network Reconfiguration Phase. In the latter case, GW sends a BEST message to every node for which the routing table has been updated. The message includes also information about the new next hop to reach the GW.</p>
<p>Upon reaching its new location, the mobile node broadcasts an
<preformat position="float" xml:space="preserve"><monospace>ADD</monospace>
</preformat>
(<italic>u<sub>m</sub>
</italic>
) message. Upon receiving the
<preformat position="float" xml:space="preserve"><monospace>ADD</monospace>
</preformat>
(<italic>u<sub>m</sub>
</italic>
) message, each node sends back an
<preformat position="float" xml:space="preserve"><monospace>ADD-ACK</monospace>
</preformat>
message containing information about link quality. The mobile node acknowledges all the received
<preformat position="float" xml:space="preserve"><monospace>ADD-ACK</monospace>
</preformat>
messages by sending back unicast
<preformat position="float" xml:space="preserve"><monospace>ADD-ACK</monospace>
</preformat>
messages, containing information about its link quality. Finally, the mobile node sends an
<preformat position="float" xml:space="preserve"><monospace>ADD-REPORT</monospace>
</preformat>
message to the GW so that the GW can accordingly update the routing tables and re-distribute them to all the interested nodes by means of
<preformat position="float" xml:space="preserve"><monospace>ADD-BEST</monospace>
</preformat>
messages.</p>
</sec>
</sec>
<sec><label>6.2.</label>
<title>A Spoofing-Based DoS Attack</title>
<p>In this section, we show that FLOOD protocol is subjected to the spoofing-based DoS attack. <xref ref-type="fig" rid="f6-sensors-12-15133">Figure 6</xref>
shows an example of how an attacker can perform a spoofing-based DoS attack in a network composed of three nodes. Whenever the attacker receives a
<preformat position="float" xml:space="preserve"><monospace>HELLO</monospace>
</preformat>
message, it can add a <italic>new fake node</italic>
and broadcast the message to the other vehicles.</p>
<p>In this way, the protocol never completes. In order to avoid this kind of attack, each node could be deployed with the list of all the nodes identifiers belonging to the system. Thus, if the attacker tries to add a new fake node to the network, each node rejects it, because the fake node is not contained in that list. However, due to the underwater conditions and to the high distances among nodes, it may happen that a node <italic>u</italic>
<sub>1</sub>
is not able to directly contact nodes <italic>u</italic>
<sub>2</sub>
and <italic>u</italic>
<sub>3</sub>
belonging to the system. The attacker could exploit this situation in order to use <italic>u</italic>
<sub>2</sub>
and <italic>u</italic>
<sub>3</sub>
identifier to perform a DoS attack.</p>
</sec>
<sec><label>6.3.</label>
<title>SeFLOOD: The Secure FLOOD</title>
<p>In order to protect the integrity and confidentiality of the FLOOD protocol we have extended it into a new protocol called <italic>secure FLOOD</italic>
(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.</p>
<p>More specifically, SeFLOOD protects confidentiality and integrity of any given control message <italic>m</italic>
by computing <italic>E<sub>e</sub>
</italic>
(<italic>m</italic>
, ⌊<italic>h</italic>
(<italic>m</italic>
)⌋<italic><sub>t</sub>
</italic>
), where <italic>E</italic>
(•) is a block cipher used in CBC-CTS mode (see Section 5), ⌊<italic>h</italic>
(•)⌋<italic><sub>t</sub>
</italic>
is a <italic>t</italic>
-bits truncated hash function (see Section 5), and <italic>e</italic>
is a symmetric key [<xref ref-type="bibr" rid="b24-sensors-12-15133">24</xref>
]. For the sake of brevity, in the following we will denote this cryptographic transformation by 〈<italic>m</italic>
〉<italic><sub>e</sub>
</italic>
. Upon receiving 〈<italic>m</italic>
〉<italic><sub>e</sub>
</italic>
, a node decrypts it by <italic>e</italic>
, verifies the digest, and checks whether <italic>m</italic>
contains some fresh quantity (e.g., a time stamp or a nonce) [<xref ref-type="bibr" rid="b33-sensors-12-15133">33</xref>
]. If the decryption and all the checks are successful, then we say that the node <italic>successfully receives</italic>
the message. Otherwise, the message is discarded.</p>
<p>Link-layer keys are distributed as follows. We assume that each pair of nodes <italic>u<sub>i</sub>
</italic>
and <italic>u<sub>j</sub>
</italic>
, <italic>i ≠ j,</italic>
secretly shares <italic>a pairwise link key ℓ<sub>ij</sub>
</italic>
, which is used to protect unicast messages between <italic>u<sub>i</sub>
</italic>
and <italic>u<sub>j</sub>
</italic>
. In order to distribute the link keys, we could use well-known key establishment schemes such as Elliptic curve Diffie-Hellman [<xref ref-type="bibr" rid="b34-sensors-12-15133">34</xref>
] or the Blundo scheme [<xref ref-type="bibr" rid="b35-sensors-12-15133">35</xref>
]. However, for both simplicity and efficiency, each node can be deployed with a <italic>Link-Key Table</italic>
(LKT) containing all the pair-wise link keys it shares with the other nodes. This solution has an <italic>O</italic>
(<italic>n</italic>
) storage overhead, where <italic>n</italic>
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 <italic>n</italic>
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.</p>
<p>Furthermore, we group nodes into <italic>clusters</italic>
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
<inline-graphic xlink:href="sensors-12-15133u1.jpg"></inline-graphic>
<italic><sub>u</sub>
</italic>
the cluster associated with node <italic>u.</italic>
It follows that we have as many clusters as nodes. Furthermore, a node may belong to one or more clusters. A given node <italic>u</italic>
certainly belongs to <italic>C<sub>u</sub>
</italic>
. Furthermore, if <italic>υ</italic>
is a neighbour of <italic>u,</italic>
then <italic>u</italic>
∈
<inline-graphic xlink:href="sensors-12-15133u1.jpg"></inline-graphic>
<italic><sub>υ</sub>
</italic>
as well.</p>
<p>Each cluster is associated to a <italic>cluster key</italic>
, which is used to secure broadcast communication among nodes belonging to the same cluster. Every node <italic>u</italic>
generates a <italic>cluster key c<sub>u</sub>
</italic>
and distributes it to all the members of its cluster. Furthermore, every node maintains a <italic>Cluster Key Table</italic>
(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.</p>
<p>Cluster keys are established by means of the following <italic>Cluster Key Distribution Protocol</italic>
(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.</p>
<list list-type="order"><list-item><p><italic>u</italic>
→ * : HELLO, <italic>u</italic>
, <italic>ν<sub>u</sub>
</italic>
</p>
</list-item>
<list-item><p><italic>υ</italic>
→ <italic>u</italic>
: 〈CLUSTER_KEY, <italic>υ</italic>
, <italic>c<sub>υ</sub>
</italic>
, <italic>ν<sub>u</sub>
</italic>
〉<italic>ℓ<sub>uυ</sub>
</italic>
</p>
</list-item>
</list>
<p>The protocol is composed of two rounds, the <italic>discovery round</italic>
and the <italic>key distribution round</italic>
. In the discovery round, a node <italic>u</italic>
generates a fresh quantity <italic>ν<sub>u</sub>
</italic>
and broadcasts it together with its identifier <italic>u</italic>
(message M6.3). Upon receiving message M6.3, a node <italic>υ</italic>
replies <italic>u</italic>
with its identifier <italic>υ</italic>
, its cluster key <italic>c<sub>v</sub>
,</italic>
and the fresh quantity <italic>ν<sub>u</sub>
</italic>
(message M6.3). The message is protected by means of the link key <italic>ℓ<sub>uv</sub>
</italic>
. Upon successfully receiving message M6.3 from <italic>υ</italic>
(otherwise, the message is discarded), node <italic>u</italic>
stores the received cluster key <italic>c<sub>v</sub>
</italic>
into its CKT</p>
<p>From a security point of view, we can argue that the encipherment by <italic>ℓ<sub>uv</sub>
</italic>
makes node <italic>u</italic>
to believe that <italic>c<sub>v</sub>
</italic>
actually comes from <italic>υ</italic>
. Furthermore, the presence of the fresh quantity <italic>ν<sub>u</sub>
</italic>
guarantees that message M6.3 is not a replay of an older message. The encipherment also guarantees the secrecy of <italic>c<sub>v</sub>
</italic>
.</p>
<p><xref ref-type="fig" rid="f7-sensors-12-15133">Figure 7</xref>
shows an execution instance of CKDP. The network is composed of three nodes, where GW corresponds to <italic>u</italic>
<sub>1</sub>
. The broadcast domain of <italic>u</italic>
<sub>1</sub>
covers only node <italic>u</italic>
<sub>2</sub>
, whereas node <italic>u</italic>
<sub>2</sub>
is able to reach both <italic>u</italic>
<sub>1</sub>
and <italic>u</italic>
<sub>3</sub>
. Node <italic>u</italic>
<sub>3</sub>
is able to reach only <italic>u</italic>
<sub>2</sub>
. At the end of the protocol three clusters are built,
<inline-graphic xlink:href="sensors-12-15133u1.jpg"></inline-graphic>
<sub>1</sub>
= {<italic>u</italic>
<sub>1</sub>
, <italic>u</italic>
<sub>2</sub>
},
<inline-graphic xlink:href="sensors-12-15133u1.jpg"></inline-graphic>
<sub>2</sub>
= {<italic>u</italic>
<sub>1</sub>
, <italic>u</italic>
<sub>2</sub>
, <italic>u</italic>
<sub>3</sub>
}, and, finally,
<inline-graphic xlink:href="sensors-12-15133u1.jpg"></inline-graphic>
<sub>3</sub>
= {<italic>u</italic>
<sub>2</sub>
, <italic>u</italic>
<sub>3</sub>
} with cluster keys <italic>c<sub>u</sub>
</italic>
<sub>1</sub>
, <italic>c<sub>u</sub>
</italic>
<sub>2</sub>
, and <italic>c<sub>u</sub>
</italic>
<sub>3</sub>
, respectively.</p>
<p>Notice that the attack described in Section 6.2 is not possible anymore. Actually, in order to play such an attack, the adversary would need to either know the cluster keys of neighbours or disseminate its own. However, none of these alternatives is possible because the adversary does not know the link keys of nodes.</p>
<sec><label>6.3.1.</label>
<title>Secure Network Reconfiguration</title>
<p>SeFLOOD also supports mobile nodes, without adding overhead in terms of number of messages. In fact, it exploits FLOOD messages sent by a mobile node in order to distribute the cluster keys. We assume that nodes have loosely synchronized clocks. This assumption is reasonable because nodes periodically emerge and synchronize their clocks with GPS, for example.</p>
<p>Assume that <italic>u<sub>m</sub>
</italic>
is a mobile node wishing to leave the network. Then, it triggers the following protocol:
<list list-type="order"><list-item><p><italic>u<sub>m</sub>
</italic>
→ <italic>GW</italic>
: 〈
<preformat position="float" xml:space="preserve"><monospace>DEL</monospace>
</preformat>
, <italic>u<sub>m</sub>
</italic>
, <italic>τ<sub>m</sub>
</italic>
〉<italic><sub>e<sub>u<sub>m</sub>
</sub>
</sub>
</italic>
</p>
</list-item>
<list-item><p><italic>GW</italic>
→ <italic>u<sub>i</sub>
</italic>
: 〈
<preformat position="float" xml:space="preserve"><monospace>BEST</monospace>
</preformat>
, <italic>u<sub>m</sub>
</italic>
, <italic>τ<sub>g</sub>
</italic>
, routing – updates<italic><sub>i</sub>
</italic>
〉<italic><sub>eui</sub>
</italic>
</p>
</list-item>
</list>
</p>
<p>Initially, <italic>u<sub>m</sub>
</italic>
sends the gateway a
<preformat position="float" xml:space="preserve"><monospace>DEL</monospace>
</preformat>
message M6.3.1 specifying its identifier and a timestamp <italic>τ<sub>u<sub>m</sub>
</sub>
</italic>
. The message is protected by means of the node end-to-end key <italic>e<sub>u<sub>m</sub>
</sub>
</italic>
.</p>
<p>Upon successfully receiving message M6.3.1 (otherwise the message is discarded), the GW deletes <italic>u<sub>m</sub>
</italic>
from the routing tables, updates the routing tables, and sends a
<preformat position="float" xml:space="preserve"><monospace>BEST</monospace>
</preformat>
message to every node whose routing table needs to be updated (message M6.3.1). The message specifies the identifier <italic>u<sub>m</sub>
</italic>
of the leaving node, a fresh quantity <italic>τ<sub>g</sub>
</italic>
and the updates to be applied to the routing table. The message is protected by means of the end-to-end key <italic>e<sub>i</sub>
</italic>
. Upon successfully receiving message M6.3.1 (otherwise the message is discarded), node <italic>u<sub>i</sub>
</italic>
updates its own routing table as specified in the message, by replacing the entries containing <italic>u<sub>m</sub>
</italic>
with the new ones calculated by the GW.</p>
<p>Assume now that the mobile node <italic>u<sub>m</sub>
</italic>
wants to join again the network. The node <italic>u<sub>m</sub>
</italic>
triggers the following protocol
<list list-type="order"><list-item><p><italic>u<sub>m</sub>
</italic>
→ *:
<preformat position="float" xml:space="preserve"><monospace>ADD</monospace>
</preformat>
, <italic>u<sub>m</sub>
</italic>
, <italic>ν<sub>um</sub>
</italic>
</p>
</list-item>
<list-item><p><italic>u<sub>i</sub>
</italic>
→ <italic>u<sub>m</sub>
</italic>
: 〈
<preformat position="float" xml:space="preserve"><monospace>ADD</monospace>
</preformat>
–
<preformat position="float" xml:space="preserve"><monospace>ACK</monospace>
</preformat>
, <italic>ν<sub>um</sub>
</italic>
, <italic>τ<sub>i</sub>
</italic>
, <italic>c<sub>ui</sub>
</italic>
〉<italic><sub>ℓ<sub>im</sub>
</sub>
</italic>
</p>
</list-item>
<list-item><p><italic>u<sub>m</sub>
</italic>
→ <italic>u<sub>i</sub>
</italic>
: 〈
<preformat position="float" xml:space="preserve"><monospace>ADD</monospace>
</preformat>
–
<preformat position="float" xml:space="preserve"><monospace>ACK</monospace>
</preformat>
, <italic>τ<sub>i</sub>
</italic>
, <italic>c<sub>um</sub>
</italic>
〉<italic><sub>ℓ<sub>im</sub>
</sub>
</italic>
</p>
</list-item>
<list-item><p><italic>u<sub>m</sub>
</italic>
→ GW: 〈
<preformat position="float" xml:space="preserve"><monospace>ADD</monospace>
</preformat>
–
<preformat position="float" xml:space="preserve"><monospace>REPORT</monospace>
</preformat>
, <italic>τ<sub>um</sub>
</italic>
, <italic>C<sub>um</sub>
</italic>
〉<italic><sub>e<sub>m</sub>
</sub>
</italic>
</p>
</list-item>
<list-item><p>GW → <italic>u<sub>i</sub>
</italic>
: 〈
<preformat position="float" xml:space="preserve"><monospace>ADD</monospace>
</preformat>
–
<preformat position="float" xml:space="preserve"><monospace>BEST</monospace>
</preformat>
, <italic>τ<sub>i</sub>
</italic>
, routing – updates<italic><sub>i</sub>
</italic>
〉<italic><sub>e<sub>i</sub>
</sub>
</italic>
</p>
</list-item>
</list>
</p>
<p>Initially, node <italic>u<sub>m</sub>
</italic>
broadcasts an
<preformat position="float" xml:space="preserve"><monospace>ADD</monospace>
</preformat>
message (M6.3.1) carrying its identifier and a nonce <italic>ν<sub>u<sub>m</sub>
</sub>
</italic>
. Upon receiving message M6.3.1 from <italic>u<sub>m</sub>
</italic>
, a node <italic>u<sub>i</sub>
</italic>
replies by means of an
<preformat position="float" xml:space="preserve"><monospace>ADD-ACK</monospace>
</preformat>
message (M6.3.1) carrying a timestamp <italic>τ<sub>i</sub>
</italic>
, the node cluster key <italic>c<sub>ui</sub>
</italic>
, and the received nonce <italic>ν<sub>um</sub>
</italic>
, all encrypted with the link key <italic>ℓ<sub>im</sub>
</italic>
. Upon successfully receiving message M6.3.1 from <italic>u<sub>i</sub>
</italic>
(otherwise the message is discarded), node <italic>u<sub>m</sub>
</italic>
replies by sending a
<preformat position="float" xml:space="preserve"><monospace>ADD-ACK</monospace>
</preformat>
message (M6.3.1) carrying the node cluster key <italic>c<sub>u<sub>m</sub>
</sub>
</italic>
and the timestamp <italic>τ<sub>i</sub>
</italic>
, all encrypted with the link key <italic>ℓ<sub>im</sub>
</italic>
. Then <italic>u<sub>m</sub>
</italic>
sends the gateway GW the members of its cluster
<inline-graphic xlink:href="sensors-12-15133u1.jpg"></inline-graphic>
<italic><sub>u<sub>m</sub>
</sub>
</italic>
(message M6.3.1). Finally the GW sends all the nodes <italic>u<sub>i</sub>
</italic>
(included <italic>u<sub>m</sub>
</italic>
) whose routing table needs to be updated an
<preformat position="float" xml:space="preserve"><monospace>ADD-BEST</monospace>
</preformat>
message (message M6.3.1), carrying the updates to the respective routing table. The message contains also the timestamp <italic>τ<sub>i</sub>
</italic>
encrypted with <italic>e<sub>i</sub>
</italic>
in order to guarantee its freshness. Upon successfully receiving this message (otherwise the message is discarded), each node applies the specified updates to its own routing table.</p>
</sec>
<sec><label>6.3.2.</label>
<title>On Evicting a Node</title>
<p>In Section 5.3 we showed that a compromised node can be logically evicted from the application layer by revoking the group key and redistributing a new one to all members but the evicted one. Of course, a compromised node must be evicted at the routing layer too, as necessary. This task can be accomplished as follows. Let <italic>u<sub>c</sub>
</italic>
be the compromised node and <italic>S<sub>c</sub>
</italic>
be the set of nodes whose respective clusters contain <italic>u<sub>c</sub>
, i.e.</italic>
, <italic>S<sub>c</sub>
</italic>
= {<italic>u|u<sub>c</sub>
</italic>
∈ <italic><inline-graphic xlink:href="sensors-12-15133u1.jpg"></inline-graphic>
<sub>u</sub>
</italic>
}.</p>
<p>In order to evict <italic>u<sub>c</sub>
,</italic>
the gateway GW eliminates <italic>u<sub>c</sub>
</italic>
from the routing tables and calculates new paths among nodes. If the new network becomes partitioned, firstly the GW informs the remaining nodes to eliminate <italic>u<sub>c</sub>
</italic>
from their neighbourhood, by triggering the Evicting Protocol (EP) and then it triggers the Network Discovery Phase to build new routing tables. Note that it is not necessary to trigger also the CKDP, because the neighbourhood of each node does not change. The Network Discovery Phase can be avoided when the network without <italic>u<sub>c</sub>
</italic>
is not partitioned.</p>
<p>During the EP phase, the GW sends an
<preformat position="float" xml:space="preserve"><monospace>EVICT</monospace>
</preformat>
message to every node <italic>u</italic>
in <italic>S<sub>c</sub>
</italic>
commanding the node to remove <italic>u<sub>c</sub>
</italic>
from its cluster
<inline-graphic xlink:href="sensors-12-15133u1.jpg"></inline-graphic>
<italic><sub>u</sub>
</italic>
.</p>
<disp-formula id="FD1"><mml:math id="mm11"><mml:mrow><mml:mo>∀</mml:mo>
<mml:mi>u</mml:mi>
<mml:mo>∈</mml:mo>
<mml:msub><mml:mi>S</mml:mi>
<mml:mi>c</mml:mi>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:mi>G</mml:mi>
<mml:mi>W</mml:mi>
<mml:mo>→</mml:mo>
<mml:mi>u</mml:mi>
<mml:mo>:</mml:mo>
<mml:msub><mml:mrow><mml:mrow><mml:mo>〈</mml:mo>
<mml:mrow><mml:mtext mathvariant="monospace">EVICT</mml:mtext>
<mml:mo>,</mml:mo>
<mml:msub><mml:mi>u</mml:mi>
<mml:mi>c</mml:mi>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:msub><mml:mi>τ</mml:mi>
<mml:mrow><mml:mi>G</mml:mi>
<mml:mi>W</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
<mml:mo>〉</mml:mo>
</mml:mrow>
</mml:mrow>
<mml:mrow><mml:msub><mml:mi>e</mml:mi>
<mml:mi>u</mml:mi>
</mml:msub>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</disp-formula>
<p>where <italic>τ<sub>GW</sub>
</italic>
is timestamp. Upon successfully receiving the
<preformat position="float" xml:space="preserve"><monospace>EVICT</monospace>
</preformat>
message (otherwise the message is discarded), node <italic>u</italic>
removes <italic>u<sub>c</sub>
</italic>
from its cluster
<inline-graphic xlink:href="sensors-12-15133u1.jpg"></inline-graphic>
<italic><sub>u</sub>
</italic>
, <italic>i.e.</italic>
,
<inline-graphic xlink:href="sensors-12-15133u1.jpg"></inline-graphic>
<italic><sub>u</sub>
</italic>
←
<inline-graphic xlink:href="sensors-12-15133u1.jpg"></inline-graphic>
<italic><sub>u</sub>
\</italic>
{<italic>u<sub>c</sub>
</italic>
}, generates a new cluster key
<inline-formula><mml:math id="mm12"><mml:mrow><mml:msubsup><mml:mi>c</mml:mi>
<mml:mi>u</mml:mi>
<mml:mo>′</mml:mo>
</mml:msubsup>
</mml:mrow>
</mml:math>
</inline-formula>
, and sends the key to every node in
<inline-graphic xlink:href="sensors-12-15133u1.jpg"></inline-graphic>
<italic><sub>u</sub>
</italic>
<disp-formula id="FD2"><mml:math id="mm13"><mml:mrow><mml:mo>∀</mml:mo>
<mml:mi>υ</mml:mi>
<mml:mo>∈</mml:mo>
<mml:msub><mml:mi>C</mml:mi>
<mml:mi>u</mml:mi>
</mml:msub>
<mml:mo>,</mml:mo>
<mml:mi>u</mml:mi>
<mml:mo>→</mml:mo>
<mml:mi>v</mml:mi>
<mml:mo>:</mml:mo>
<mml:msub><mml:mrow><mml:mrow><mml:mo>〈</mml:mo>
<mml:mrow><mml:mtext>CLU</mml:mtext>
<mml:mo>−</mml:mo>
<mml:mtext>KEY</mml:mtext>
<mml:mo>,</mml:mo>
<mml:mi>u</mml:mi>
<mml:mo>,</mml:mo>
<mml:msubsup><mml:mi>c</mml:mi>
<mml:mi>u</mml:mi>
<mml:mo>′</mml:mo>
</mml:msubsup>
<mml:mo>,</mml:mo>
<mml:msub><mml:mi>τ</mml:mi>
<mml:mi>u</mml:mi>
</mml:msub>
</mml:mrow>
<mml:mo>〉</mml:mo>
</mml:mrow>
</mml:mrow>
<mml:mrow><mml:mi>ℓ</mml:mi>
<mml:mi>u</mml:mi>
<mml:mi>v</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:math>
</disp-formula>
</p>
</sec>
</sec>
</sec>
<sec><label>7.</label>
<title>Performance Evaluation</title>
<sec><label>7.1.</label>
<title>Performance Evaluation of the CryptoSuite</title>
<p>In this section we report the performance analysis of our cryptographic suite through experimental tests performed within the UAN experimental campaign conducted on May 2011 in Norway [<xref ref-type="bibr" rid="b5-sensors-12-15133">5</xref>
].</p>
<p><xref ref-type="fig" rid="f8-sensors-12-15133">Figure 8</xref>
shows the topology of the underwater acoustic network, which constituted the testbed during the experiments. It is composed of a gateway GW, two fixed nodes (FN1 and FN2) and two UAVs (FLG1 and FLG2). <xref ref-type="fig" rid="f9-sensors-12-15133">Figure 9</xref>
shows the real devices we used in the experiments. Notice that the gateway (<xref ref-type="fig" rid="f9-sensors-12-15133">Figure 9(a)</xref>
) is equal to a fixed node (<xref ref-type="fig" rid="f9-sensors-12-15133">Figure 9(c)</xref>
) except for the optical fiber that connect the device to the asset (blue cable). UAVs are of Folaga type, manufactured by GraalTech Inc. [<xref ref-type="bibr" rid="b36-sensors-12-15133">36</xref>
] (<xref ref-type="fig" rid="f9-sensors-12-15133">Figure 9(b)</xref>
). From a computing platform standpoint, all these computers are equipped with a 1 GHz VIA EDEN Ultra Low Voltage Processor, 1 Gbytes of RAM (DRAM DDR2 533/400 on SO-DIMM socket Chipset VIA CX700M), and run the Linux Ubuntu 10.4 Operating System. All underwater nodes are equipped with an acoustic modem developed by Kongsberg Maritime, a UAN partner, and providing a maximum transmission rate <italic>r</italic>
<sub>max</sub>
500 bits/s.</p>
<p>The GW is placed at a depth of 96 m. FN1 and FN2 are at a depth of 96 m and 39 m, at a distance from the GW of 163.5 m and 860 m, respectively. The nodes FLG1 and FLG2 are placed at a depth of 20 m and 15 m, with an initial distance from the GW of 677.8 m and 687.1 m, respectively. These values are summarized in <xref ref-type="table" rid="t1-sensors-12-15133">Table 1</xref>
.</p>
<p>In the experiments, we used AES in the CBC-CTS mode as cipher for confidentiality and SHA-2 as hash function for integrity. SHA-2 produces a 256-bit output that we truncate at 32 bits. It follows that guaranteeing secrecy and integrity gives rise to a message expansion of 4 bytes.</p>
<p>In the experiments, the payload varied in between 32 and 78 bytes. This means that the 4 bytes message size increment due to security varies in between 5.13% and 12%. This increment, of course, reflects on the increased transmission time.</p>
<p>Underwater acoustic communication is particularly affected by noise and subject to the highly variable sea environmental conditions. For this reason, an increased message length due to security might reflect in an increased likelihood of message loss or corruption. In order to evaluate this impact of security on performance we have considered <italic>Average Delivery Ratio</italic>
(ADR), which is the ratio between the average number of received messages and the number of sent messages. In practice, the average delivery ratio measures the fraction of messages the network is able to deliver. Ideally, the ADR should be equal to 1.</p>
<p>We have compared the ADR when security is disabled to the ADR when security is enabled. The results are reported in <xref ref-type="fig" rid="f10-sensors-12-15133">Figure 10</xref>
. In particular, the figure shows the ADR for nodes FN2 and FLG2. We note that the ADR when security is enabled is smaller than that when security is disabled. In particular, when security is enabled, the ADR seems to suffer a decrement of 4.9% in the case of a fixed node, and 7.8% in the case of a mobile node. These variations in the ADR could be caused by an increase in the message length due to security. On the other hand, such a small percentage variations may be well depend on the change of sea conditions during the day as experiments, with security enabled and disabled respectively, were conducted at a distance of quite a few hours from each other for logistic and organizational reasons. More details about environmental conditions—e.g., water, winds, salinity, or temperatures—can be found in [<xref ref-type="bibr" rid="b5-sensors-12-15133">5</xref>
]. For these reasons, we can safely conclude that the cryptographic suite add a negligible overhead to the underwater acoustic communication.</p>
<p>In an aside, the highly variable sea conditions and their impact on the communication performance become particularly evident when you consider delay. It is well-known that underwater acoustic networks are characterized by very high delay variance which is extremely harmful for efficient protocol design, as it prevents from accurately estimating the round trip time (RTT), which is the key parameter for many common communication protocols [<xref ref-type="bibr" rid="b1-sensors-12-15133">1</xref>
]. <xref ref-type="fig" rid="f11-sensors-12-15133">Figure 11</xref>
shows the average round-trip time we have experienced in our experiments. Of course, the packet size increment due to integrity is not sufficient to explain the extremely large increments in the round-trip time. Actually, at a transmission rate of 500 bit/s, the additional 4 bytes would introduce just a 64 ms delay. As discussed above, the experiments with security disabled and those with security enabled were carried quite a few hours apart. In such a lapse of time, sea conditions have changed a lot so causing largely different delays.</p>
</sec>
<sec><label>7.2.</label>
<title>Performance Evaluation of SeFLOOD</title>
<p>Performance of SeFLOOD has been evaluated in terms of overhead that security solutions add to FLOOD. Our evaluation encompasses both the network discovery phase and the reconfiguration phase. Such an evaluation has been carried out through a simulative approach using the SimPy simulator [<xref ref-type="bibr" rid="b37-sensors-12-15133">37</xref>
]. In the simulations we have used realistic results obtained during the field experimental campaign of the UAN project [<xref ref-type="bibr" rid="b5-sensors-12-15133">5</xref>
]. In particular, we have used an average Round Trip Time equal to about 19 s when the maximum underwater acoustic transmission rate is 500 bits/s.</p>
<p>We have considered a network composed of seven fixed nodes, the gateway GW, and one mobile node. For each node we have assumed a maximum transmission power of 189 dB re <italic>μ</italic>
Pa, a transmission range of 2 km, and a working depth of 200 m. Furthermore, we have considered two deployment scenarios aimed at evaluating performance in two different network topologies: (i) a <italic>sparse scenario</italic>
, where each node has two neighbours; and (ii) a <italic>dense scenario</italic>
, where each node has five neighbours (see <xref ref-type="fig" rid="f12-sensors-12-15133">Figure 12</xref>
).</p>
<p>The HELLO and CLUSTER KEY messages in the Cluster Key Distribution Protocol (CKDP) have been implemented as follows. The HELLO message is composed of the following fields: (i) <italic>msg-type</italic>
(8 bits), that specifies the message type; (ii) <italic>node-id</italic>
(16 bits), that specifies the node identifier; (iii) <italic>nonce</italic>
(16 bit); and, the (iv) <italic>additional information</italic>
(24 bit), that specifies additional information (e.g., sea conditions). The CLUSTER KEY message is composed of the following fields: (i) <italic>msg-type</italic>
(8 bits); (ii) <italic>node-id</italic>
(16 bits); (iii) <italic>nonce</italic>
(16 bit); the (iv) <italic>key</italic>
(128 bit), that specifies the cluster key; and, the (v) <italic>digest</italic>
(24 bit), that specifies the digest. It follows that the size in bits of an HELLO message is 64 (8 bytes) whereas the size of a CLUSTER KEY message is 192 (24 bytes).</p>
<p>We have evaluated the performance of SeFLOOD with respect to two metrics: (a) the <italic>number of messages</italic>
(<italic>NoM</italic>
), and (b) the <italic>number of bits</italic>
(<italic>NoB</italic>
). The <italic>NoM</italic>
and <italic>NoB</italic>
metrics measure how much communication overhead SeFLOOD adds to FLOOD in terms of total number of sent messages and total number of sent bits, respectively. Each metric <italic>M</italic>
specifies the percentage increase of SeFLOOD with respect to FLOOD:
<disp-formula id="FD3"><label>(1)</label>
<mml:math id="mm14"><mml:mrow><mml:mi>M</mml:mi>
<mml:mo>=</mml:mo>
<mml:mfrac><mml:mrow><mml:msub><mml:mi>M</mml:mi>
<mml:mi>S</mml:mi>
</mml:msub>
<mml:mo>-</mml:mo>
<mml:msub><mml:mi>M</mml:mi>
<mml:mi>F</mml:mi>
</mml:msub>
</mml:mrow>
<mml:mrow><mml:msub><mml:mi>M</mml:mi>
<mml:mi>F</mml:mi>
</mml:msub>
</mml:mrow>
</mml:mfrac>
<mml:mo>×</mml:mo>
<mml:mn>100</mml:mn>
</mml:mrow>
</mml:math>
</disp-formula>
where <italic>M<sub>S</sub>
</italic>
represents the value of the metric for the SeFLOOD protocol, while <italic>M<sub>F</sub>
</italic>
represents the same metric for the FLOOD protocol. Each metric has been computed as an average over fifteen runs, each lasting 5,000 s. <xref ref-type="table" rid="t2-sensors-12-15133">Table 2</xref>
resumes the simulation parameters.</p>
<p><xref ref-type="fig" rid="f13-sensors-12-15133">Figure 13</xref>
shows the <italic>NoM</italic>
in both the dense and sparse scenario. As to <italic>NoM</italic>
, we only consider the discovery messages and neglect the add and delete messages because SeFLOOD does not add messages to the Reconfiguration Phase and thus SeFLOOD and FLOOD have the same number of messages in this phase. <xref ref-type="fig" rid="f14-sensors-12-15133">Figure 14</xref>
shows <italic>NoB</italic>
, which, instead, considers all types of messages.</p>
<p>As to the Discovery Phase, the additional messages introduced by SeFLOOD derive from the Cluster Key Distribution Protocol (CKDP).</p>
<p>In particular, FLOOD sends 17 messages in the dense scenario and 13 messages in the sparse scenario. SeFLOOD, instead, sends 73 messages in the dense scenario and 40 messages in the sparse scenario. It follows that <italic>NoM</italic>
is ≈ 330% in the dense scenario and ≈ 200% in the sparse scenario.</p>
<p>As to <italic>NoB</italic>
, we have first to observe that the size of the CKDP messages is fixed whereas the size of FLOOD is variable. As argued above, the CKDP messages are 64 and 192 bit in size. In contrast, a FLOOD discovery message has a minimum size of 200–400 bits [<xref ref-type="bibr" rid="b31-sensors-12-15133">31</xref>
]. Furthermore, as it carries both list of the nodes through which the message has propagated and the link quality report, the message length increases with the message propagation (Section 6.1.1). By simulations, we have evaluated that the average size of a FLOOD discovery message is about 1 Kbyte in both scenarios. It follows that CKDP messages tend to be much smaller than FLOOD discovery messages.</p>
<p>From these considerations, it turns out that although the CKDP protocol causes additional messages, the resulting overall additional traffic may be negligible with respect to the FLOOD discovery traffic. In details, FLOOD sends 144,580 bits in the dense scenario and 88,856 bits in the sparse one, while CKDP sends 9,792 bits in the dense scenario and 4,032 bits in the sparse one. Therefore, <italic>NoB</italic>
is ≈ 6% in the dense scenario and ≈ 4% in the sparse one.</p>
<p>It turns out that while the additional round of messages required by CKDP causes the discovery phase in SeFLOOD to get longer than FLOOD, the additional SeFLOOD traffic results instead practically negligible with respect to the overall FLOOD traffic. Such a negligible traffic also makes the additional SeFLOOD energy overhead practically negligible with respect to the overall FLOOD energy overhead.</p>
<p>As to reconfiguration phase, SeFLOOD does not introduce any additional message with respect to FLOOD. SeFLOOD introduces some overhead in terms of <italic>NoB</italic>
because they convey authenticators for integrity and proof of origin. Such an overhead is at most 1% (see <xref ref-type="fig" rid="f14-sensors-12-15133">Figure 14</xref>
).</p>
<p>However, it is worthwhile to notice that CKDP assumes a random deployment according to which a node cannot know its neighbourhood until deployment is completed. However, and underwater acoustic network is often employed in mission-oriented systems such as the surveillance system considered in the UAN project. In such systems, nodes are initially located in predefined locations. Therefore, a node knows in advance its <italic>potential</italic>
neighbours. Of course, depending on the sea conditions, a potential neighbour becomes an <italic>actual</italic>
one if it can actually communicate with the node. If a node knows its <italic>potential</italic>
neighbourhood in advance, then the first phase of CKDP, namely the discovery phase, can be completely avoided. Then, during the key distribution phase, the node is able to recognize its <italic>effective</italic>
neighbors. This allows SeFLOOD to reduce the number of sent discovery messages and bits and makes the protocol faster.</p>
</sec>
<sec><label>7.3.</label>
<title>On Packet Loss</title>
<p>Underwater acoustic networks are prone to packet loss. If we consider the packet loss (PL) as the ratio between the average number of lost packets and the number of sent packets, then PL = 1 − ADR (Section 7.1). It follows that in our experiments we experienced a packet loss that ranges from 32.8% to 61.5% (see <xref ref-type="fig" rid="f10-sensors-12-15133">Figure 10</xref>
).</p>
<p>As it turns out, the problem of reliable communication is certainly important in UASNs but it is largely orthogonal to the problem of secure communication and thus we do not address it here. Interested readers can refer to the literature [<xref ref-type="bibr" rid="b1-sensors-12-15133">1</xref>
,<xref ref-type="bibr" rid="b38-sensors-12-15133">38</xref>
]. Notwithstanding, the security suite has been designed in such a way that it does not negatively interfere with reliable communication. In order to achieve this goal we have adopted three main solutions. First of all, we have limited the ciphertext expansion phenomenon by properly designing the cryptographic primitives (Section 5).</p>
<p>Second, we have used the User Datagram Protocol (UDP) in key management protocols of the security suite, namely, the Group Key Management Protocol (Section 5.3) and the Cluster Key Distribution Protocol (Section 6.3). In an underwater acoustic network, UDP presents several advantages with respect to connection-oriented protocols such as TCP. Mainly, UDP does not require an end-to-end connection, and therefore entirely avoids all the connection management issues that are typical of connection-oriented protocols and that cause them to perform poorly in a networking environment that is characterized by long delays and large losses. Of course, the main drawback of UDP is that it does not provide the same level of reliability in message delivery. Therefore, services such as packet re-transmission have to be moved to the upper layers. Here, it comes the third solution we have adopted.</p>
<p>As to the Group Key Management Protocol, if any node misses any of the rekeying messages then the node fails to receive the new group key <italic>g</italic>
<sup>+</sup>
. However, upon the next group communication, the node will be able to detect the missing event because it is not able to decrypt the received messages. The node can thus recover the key directly from the gateway GW.</p>
<p>Similarly, in the Cluster Key Distribution Protocol, if any node misses any key distribution message, the node fails to receive a cluster key <italic>c</italic>
. However, upon the next cluster communication, the node will be able to detect the missing event because it is not able to decrypt the received messages. The node can thus recover the cluster key directly from the cluster head.</p>
</sec>
</sec>
<sec sec-type="conclusions"><label>8.</label>
<title>Conclusions</title>
<p>In this paper, we have presented a suite for secure underwater acoustic communication. The security suite comprises a routing protocol and a set of cryptographic primitives (cipher, digest, and re-keying), and has been designed to protect the confidentiality and the integrity while taking into account the unique characteristic and constraints of the underwater networking environment. Experiments and simulations have shown that the security suite introduces limited and sometimes negligible overhead, and thus it is perfectly adequate for the underwater acoustic communication. In particular, the suite achieves the following results.</p>
<list list-type="bullet"><list-item><p>The cryptographic suite provides efficiency by limiting the effect of ciphertext expansion. The resulting overhead is indistinguishable from the performance fluctuations due to the changing sea conditions.</p>
</list-item>
<list-item><p>The Discovery Phase of the secure routing protocol introduces an additional round, and thus a consequent delay, with respect to the insecure protocol. However it causes a negligible additional communication overhead (smaller than 6%). The overhead of the Discovery Phase is paid at system bootstrap and it is amortized over the whole system lifetime.</p>
</list-item>
<list-item><p>The Reconfiguration Phase of the routing protocol does not introduce any additional overhead with respect to the insecure routing protocol. This is a very important feature because network reconfiguration due to node mobility, joining and leaving the application is a normal operational mode of the system.</p>
</list-item>
<list-item><p>The design of the secure routing protocol meets the well-known Lampson's recommendations for computer systems design [<xref ref-type="bibr" rid="b39-sensors-12-15133">39</xref>
], while reconfiguration must be very efficient, it is sufficient that discovery is able to make progress provided it remains practically sustainable.</p>
</list-item>
</list>
<p>To the best of our knowledge, this is the first work that provides a complete, practical, and efficient solution to integrity and confidentiality for UASNs. In this respect, we hope that our work will have a significant impact in this field.</p>
</sec>
</body>
<back><ack><p>We wish to thanks the anonymous reviewers for their comments and suggestions leading to an improved presentation.</p>
<p>This work has been partially supported by the EU FP7 Project UAN (Grant Agreement No. FP7-2007-2013-225669), and the EU FP7 Network of Excellence CONET (Grant Agreement No. FP7-2007-2-224053).</p>
</ack>
<ref-list><title>References</title>
<ref id="b1-sensors-12-15133"><label>1.</label>
<element-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Akyildiz</surname>
<given-names>I.F.</given-names>
</name>
<name><surname>Pompili</surname>
<given-names>D.</given-names>
</name>
<name><surname>Melodia</surname>
<given-names>T.</given-names>
</name>
</person-group>
<article-title>Underwater acoustic sensor networks: Research challenges</article-title>
<source>Ad Hoc Netw.</source>
<year>2005</year>
<volume>3</volume>
<fpage>257</fpage>
<lpage>279</lpage>
</element-citation>
</ref>
<ref id="b2-sensors-12-15133"><label>2.</label>
<element-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Domingo</surname>
<given-names>M.</given-names>
</name>
</person-group>
<article-title>Securing underwater wireless communication networks</article-title>
<source>Wirel. Commun.</source>
<year>2011</year>
<volume>18</volume>
<fpage>22</fpage>
<lpage>28</lpage>
</element-citation>
</ref>
<ref id="b3-sensors-12-15133"><label>3.</label>
<element-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Ca′rdenas</surname>
<given-names>A.A.</given-names>
</name>
<name><surname>Roosta</surname>
<given-names>T.</given-names>
</name>
<name><surname>Sastry</surname>
<given-names>S.</given-names>
</name>
</person-group>
<article-title>Rethinking security properties, threat models, and the design space in sensor networks: A case study in SCADA systems</article-title>
<source>Ad Hoc Netw.</source>
<year>2009</year>
<volume>7</volume>
<fpage>1434</fpage>
<lpage>1447</lpage>
</element-citation>
</ref>
<ref id="b4-sensors-12-15133"><label>4.</label>
<element-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Yick</surname>
<given-names>J.</given-names>
</name>
<name><surname>Mukherjee</surname>
<given-names>B.</given-names>
</name>
<name><surname>Ghosal</surname>
<given-names>D.</given-names>
</name>
</person-group>
<article-title>Wireless sensor network survey</article-title>
<source>Comput. Netw.</source>
<year>2008</year>
<volume>52</volume>
<fpage>2292</fpage>
<lpage>2330</lpage>
</element-citation>
</ref>
<ref id="b5-sensors-12-15133"><label>5.</label>
<element-citation publication-type="webpage"><article-title>The UAN Project</article-title>
<comment>Available online: <ext-link ext-link-type="uri" xlink:href="http://www.ua-net.eu">http://www.ua-net.eu</ext-link>
(accessed on 6 November 2012)</comment>
</element-citation>
</ref>
<ref id="b6-sensors-12-15133"><label>6.</label>
<element-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Jiang</surname>
<given-names>H.</given-names>
</name>
<name><surname>Feng</surname>
<given-names>Y.X.</given-names>
</name>
</person-group>
<article-title>Research advances on security problems of underwater sensor networks</article-title>
<source>Adv. Mater. Res.</source>
<year>2011</year>
<volume>317–319</volume>
<fpage>1002</fpage>
<lpage>1006</lpage>
</element-citation>
</ref>
<ref id="b7-sensors-12-15133"><label>7.</label>
<element-citation publication-type="confproc"><person-group person-group-type="author"><name><surname>Yang</surname>
<given-names>G.</given-names>
</name>
<name><surname>Wei</surname>
<given-names>Z.</given-names>
</name>
<name><surname>Cong</surname>
<given-names>Y.</given-names>
</name>
<name><surname>Jia</surname>
<given-names>D.</given-names>
</name>
</person-group>
<article-title>Analysis of Security and Threat of Underwater Wireless Sensor Network Topology</article-title>
<conf-name>Proceedings of the 4th International Conference on Digital Image Processing</conf-name>
<conf-loc>Kuala Lumpur, Malaysia</conf-loc>
<conf-date>7–8 April 2012</conf-date>
</element-citation>
</ref>
<ref id="b8-sensors-12-15133"><label>8.</label>
<element-citation publication-type="confproc"><person-group person-group-type="author"><name><surname>Dong</surname>
<given-names>Y.</given-names>
</name>
<name><surname>Liu</surname>
<given-names>P.</given-names>
</name>
</person-group>
<article-title>Security Considerations of Underwater Acoustic Networks</article-title>
<conf-name>Proceedings of the 20th International Congress on Acoustics</conf-name>
<conf-loc>Sydney, Australia</conf-loc>
<conf-date>23–27 August 2010</conf-date>
</element-citation>
</ref>
<ref id="b9-sensors-12-15133"><label>9.</label>
<element-citation publication-type="confproc"><person-group person-group-type="author"><name><surname>Dong</surname>
<given-names>Y.</given-names>
</name>
<name><surname>Liu</surname>
<given-names>P.</given-names>
</name>
</person-group>
<article-title>A Comparison of Two Secure Routing Protocols in Underwater Acoustic Network</article-title>
<conf-name>Proceedings of the 20th International Congress on Acoustics</conf-name>
<conf-loc>Sydney, Australia</conf-loc>
<conf-date>23–27 August 2010</conf-date>
</element-citation>
</ref>
<ref id="b10-sensors-12-15133"><label>10.</label>
<element-citation publication-type="confproc"><person-group person-group-type="author"><name><surname>Dong</surname>
<given-names>Y.</given-names>
</name>
<name><surname>Liu</surname>
<given-names>P.</given-names>
</name>
</person-group>
<article-title>Simulation Study on Self-Reorganization of Underwater Acoustic Networks</article-title>
<conf-name>Proceedings of the International Conference on Information and Automation</conf-name>
<conf-loc>Shenzhen, China</conf-loc>
<conf-date>6–8 June 2011</conf-date>
<fpage>595</fpage>
<lpage>600</lpage>
</element-citation>
</ref>
<ref id="b11-sensors-12-15133"><label>11.</label>
<element-citation publication-type="confproc"><person-group person-group-type="author"><name><surname>Zhang</surname>
<given-names>R.</given-names>
</name>
<name><surname>Zhang</surname>
<given-names>Y.</given-names>
</name>
</person-group>
<article-title>Wormhole-Resilient Secure Neighbor Discovery in Underwater Acoustic Networks</article-title>
<conf-name>Proceedings of the 29th IEEE International Conference on Computer Communications, Joint Conference of the IEEE Computer and Communications Societies</conf-name>
<conf-loc>San Diego, CA, USA</conf-loc>
<conf-date>14 March 2010</conf-date>
<fpage>2633</fpage>
<lpage>2641</lpage>
</element-citation>
</ref>
<ref id="b12-sensors-12-15133"><label>12.</label>
<element-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Wang</surname>
<given-names>W.</given-names>
</name>
<name><surname>Kong</surname>
<given-names>J.</given-names>
</name>
<name><surname>Bhargava</surname>
<given-names>B.K.</given-names>
</name>
<name><surname>Gerla</surname>
<given-names>M.</given-names>
</name>
</person-group>
<article-title>Visualisation of wormholes in underwater sensor networks: A distributed approach</article-title>
<source>Int. J. Secur. Netw.</source>
<year>2008</year>
<volume>3</volume>
<fpage>10</fpage>
<lpage>23</lpage>
</element-citation>
</ref>
<ref id="b13-sensors-12-15133"><label>13.</label>
<element-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Zuba</surname>
<given-names>M.</given-names>
</name>
<name><surname>Shi</surname>
<given-names>Z.</given-names>
</name>
<name><surname>Peng</surname>
<given-names>Z.</given-names>
</name>
<name><surname>Cui</surname>
<given-names>J.H.</given-names>
</name>
<name><surname>Zhou</surname>
<given-names>S.</given-names>
</name>
</person-group>
<article-title>Vulnerabilities of underwater acoustic networks to denial-of-service jamming attacks</article-title>
<source>Secur. Commun. Netw.</source>
<year>2012</year>
<pub-id pub-id-type="doi">10.1002/sec.507</pub-id>
</element-citation>
</ref>
<ref id="b14-sensors-12-15133"><label>14.</label>
<element-citation publication-type="confproc"><person-group person-group-type="author"><name><surname>Liu</surname>
<given-names>Y.</given-names>
</name>
<name><surname>Jing</surname>
<given-names>J.</given-names>
</name>
<name><surname>Yang</surname>
<given-names>J.</given-names>
</name>
</person-group>
<article-title>Secure Underwater Acoustic Communication Based on a Robust Key Generation Scheme</article-title>
<conf-name>Proceedings of the 9th International Conference on Signal Processing</conf-name>
<conf-loc>Beijing, China</conf-loc>
<conf-date>10–11 May 2008</conf-date>
<fpage>1838</fpage>
<lpage>1841</lpage>
</element-citation>
</ref>
<ref id="b15-sensors-12-15133"><label>15.</label>
<element-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Liu</surname>
<given-names>C.G.</given-names>
</name>
<name><surname>Chao</surname>
<given-names>C.H.</given-names>
</name>
<name><surname>Leou</surname>
<given-names>C.W.</given-names>
</name>
<name><surname>Li</surname>
<given-names>J.S.</given-names>
</name>
</person-group>
<article-title>Iterative key distribution based on MAD neighborhood in underwater mobile sensor networks</article-title>
<source>Comput. J.</source>
<year>2012</year>
<pub-id pub-id-type="doi">10.1093/comjnl/bxs031</pub-id>
</element-citation>
</ref>
<ref id="b16-sensors-12-15133"><label>16.</label>
<element-citation publication-type="confproc"><person-group person-group-type="author"><name><surname>Cong</surname>
<given-names>Y.</given-names>
</name>
<name><surname>Yang</surname>
<given-names>G.</given-names>
</name>
<name><surname>Wei</surname>
<given-names>Z.</given-names>
</name>
<name><surname>Zhou</surname>
<given-names>W.</given-names>
</name>
</person-group>
<article-title>Security in Underwater Sensor Network</article-title>
<conf-name>Proceedings of the International Conference on Communications and Mobile Computing</conf-name>
<conf-loc>Shenzen, China</conf-loc>
<conf-date>12–14 April 2010</conf-date>
<comment>Volume 1</comment>
<fpage>162</fpage>
<lpage>168</lpage>
</element-citation>
</ref>
<ref id="b17-sensors-12-15133"><label>17.</label>
<element-citation publication-type="confproc"><person-group person-group-type="author"><name><surname>Dini</surname>
<given-names>G.</given-names>
</name>
<name><surname>Lo Duca</surname>
<given-names>A.</given-names>
</name>
</person-group>
<article-title>A Cryptographic Suite for Underwater Cooperative Applications</article-title>
<conf-name>Proceedings of IEEE International Symposium on Computers and Communications</conf-name>
<conf-loc>Kerkyra, Greece</conf-loc>
<conf-date>June 2011</conf-date>
<fpage>870</fpage>
<lpage>875</lpage>
</element-citation>
</ref>
<ref id="b18-sensors-12-15133"><label>18.</label>
<element-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Caiti</surname>
<given-names>A.</given-names>
</name>
<name><surname>Calabrò</surname>
<given-names>V.</given-names>
</name>
<name><surname>Dini</surname>
<given-names>G.</given-names>
</name>
<name><surname>Lo Duca</surname>
<given-names>A.</given-names>
</name>
<name><surname>Munafò</surname>
<given-names>A.</given-names>
</name>
</person-group>
<article-title>Secure cooperation of autonomous mobile sensors using an underwater acoustic network</article-title>
<source>Sensors</source>
<year>2012</year>
<volume>12</volume>
<fpage>1967</fpage>
<lpage>1989</lpage>
<pub-id pub-id-type="pmid">22438748</pub-id>
</element-citation>
</ref>
<ref id="b19-sensors-12-15133"><label>19.</label>
<element-citation publication-type="confproc"><person-group person-group-type="author"><name><surname>Dini</surname>
<given-names>G.</given-names>
</name>
<name><surname>Lo Duca</surname>
<given-names>A.</given-names>
</name>
</person-group>
<article-title>SeFLOOD: A Secure Network Discovery Protocol for Underwater Acoustic Networks</article-title>
<conf-name>Proceedings of IEEE International Symposium on Computers and Communications</conf-name>
<conf-loc>Kerkyra, Greece</conf-loc>
<conf-date>28 June–1 July 2011</conf-date>
<fpage>636</fpage>
<lpage>638</lpage>
</element-citation>
</ref>
<ref id="b20-sensors-12-15133"><label>20.</label>
<element-citation publication-type="confproc"><person-group person-group-type="author"><name><surname>Caiti</surname>
<given-names>A.</given-names>
</name>
<name><surname>Munafó</surname>
<given-names>A.</given-names>
</name>
</person-group>
<article-title>Adaptive Cooperative Algorithms for AUV Networks</article-title>
<conf-name>Proceedings of the IEEE International Conference on Communications Workshops</conf-name>
<conf-loc>Cape Town, South Africa</conf-loc>
<conf-date>23–27 May 2010</conf-date>
<fpage>1</fpage>
<lpage>5</lpage>
</element-citation>
</ref>
<ref id="b21-sensors-12-15133"><label>21.</label>
<element-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Stojanovic</surname>
<given-names>M.</given-names>
</name>
</person-group>
<article-title>On the relationship between capacity and distance in an underwater acoustic communication channel</article-title>
<source>ACM Mobile Comput. Commun. Rev.</source>
<year>2007</year>
<volume>11</volume>
<fpage>34</fpage>
<lpage>43</lpage>
</element-citation>
</ref>
<ref id="b22-sensors-12-15133"><label>22.</label>
<element-citation publication-type="confproc"><person-group person-group-type="author"><name><surname>Arkin</surname>
<given-names>R.</given-names>
</name>
<name><surname>Grupen</surname>
<given-names>R.</given-names>
</name>
</person-group>
<article-title>Behaviour-Based Reactive Robotic Systems</article-title>
<conf-name>Proceedings of the IEEE International Conference on Robotics and Automation</conf-name>
<conf-loc>Atlanta, GA, USA</conf-loc>
<conf-date>2–6 May 1993</conf-date>
</element-citation>
</ref>
<ref id="b23-sensors-12-15133"><label>23.</label>
<element-citation publication-type="book"><person-group person-group-type="author"><name><surname>Arkin</surname>
<given-names>R.C.</given-names>
</name>
</person-group>
<source>Behavior-Based Robots</source>
<publisher-name>The MIT Press</publisher-name>
<publisher-loc>Cambridge, MA, USA</publisher-loc>
<year>1998</year>
</element-citation>
</ref>
<ref id="b24-sensors-12-15133"><label>24.</label>
<element-citation publication-type="confproc"><person-group person-group-type="author"><name><surname>Menezes</surname>
<given-names>A.J.</given-names>
</name>
<name><surname>van Oorschot</surname>
<given-names>P.C.</given-names>
</name>
<name><surname>Vanstone</surname>
<given-names>S.A.</given-names>
</name>
</person-group>
<source>Handbook of Applied Cryptography</source>
<publisher-name>CRC Press</publisher-name>
<publisher-loc>Boca Raton, FL, USA</publisher-loc>
<year>1996</year>
</element-citation>
</ref>
<ref id="b25-sensors-12-15133"><label>25.</label>
<element-citation publication-type="confproc"><person-group person-group-type="author"><name><surname>Patron</surname>
<given-names>P.</given-names>
</name>
<name><surname>Petillot</surname>
<given-names>Y.</given-names>
</name>
</person-group>
<article-title>The Underwater Environment: A Challenge for Planning</article-title>
<conf-name>Proceedings of the 27th Workshop of the UK Planning and Scheduling Special Interest Group</conf-name>
<publisher-name>Edinburgh, UK</publisher-name>
<conf-date>11–12 December 2008</conf-date>
</element-citation>
</ref>
<ref id="b26-sensors-12-15133"><label>26.</label>
<element-citation publication-type="confproc"><person-group person-group-type="author"><name><surname>Fagiolini</surname>
<given-names>A.</given-names>
</name>
<name><surname>Pellinacci</surname>
<given-names>M.</given-names>
</name>
<name><surname>Valenti</surname>
<given-names>G.</given-names>
</name>
<name><surname>Dini</surname>
<given-names>G.</given-names>
</name>
<name><surname>Bicchi</surname>
<given-names>A.</given-names>
</name>
</person-group>
<article-title>Consensus-Based Distributed Intrusion Detection for Multi-Robot Systems</article-title>
<conf-name>Proceedings of the International Conference on Robotics and Automation</conf-name>
<conf-loc>Pasadena, CA, USA</conf-loc>
<conf-date>20–22 May 2008</conf-date>
<fpage>120</fpage>
<lpage>127</lpage>
</element-citation>
</ref>
<ref id="b27-sensors-12-15133"><label>27.</label>
<element-citation publication-type="book"><person-group person-group-type="author"><name><surname>Schneier</surname>
<given-names>B.</given-names>
</name>
</person-group>
<source>Applied Cryptography: Protocols, Algorithms, and Source Code in C</source>
<edition>2nd ed.</edition>
<publisher-name>John Wiley & Sons Inc.</publisher-name>
<publisher-loc>New York, NY, USA</publisher-loc>
<year>1995</year>
<fpage>191</fpage>
<lpage>195</lpage>
</element-citation>
</ref>
<ref id="b28-sensors-12-15133"><label>28.</label>
<element-citation publication-type="confproc"><person-group person-group-type="author"><name><surname>Karlof</surname>
<given-names>C.</given-names>
</name>
<name><surname>Sastry</surname>
<given-names>N.</given-names>
</name>
<name><surname>Wagner</surname>
<given-names>D.</given-names>
</name>
</person-group>
<article-title>TinySec: A Link Layer Security Architecture for Wireless Sensor Networks</article-title>
<conf-name>Proceedings of the 2nd International Conference on Embedded Networked Sensor Systems</conf-name>
<publisher-name>Baltimore, MD, USA</publisher-name>
<conf-date>3–5 November 2004</conf-date>
<fpage>162</fpage>
<lpage>175</lpage>
</element-citation>
</ref>
<ref id="b29-sensors-12-15133"><label>29.</label>
<element-citation publication-type="confproc"><person-group person-group-type="author"><name><surname>Dini</surname>
<given-names>G.</given-names>
</name>
<name><surname>Savino</surname>
<given-names>I.M.</given-names>
</name>
</person-group>
<article-title>An Efficient Key Revocation Protocol for Wireless Sensor Networks</article-title>
<conf-name>Proceedings of the International Symposium on a World of Wireless, Mobile and Multimedia Networks</conf-name>
<conf-loc>Niagara Falls, NY, USA</conf-loc>
<conf-date>26–29 June 2006</conf-date>
</element-citation>
</ref>
<ref id="b30-sensors-12-15133"><label>30.</label>
<element-citation publication-type="confproc"><person-group person-group-type="author"><name><surname>Dini</surname>
<given-names>G.</given-names>
</name>
<name><surname>Savino</surname>
<given-names>I.M.</given-names>
</name>
</person-group>
<article-title>S2RP: A Secure and Scalable Rekeying Protocol for Wireless Sensor Networks</article-title>
<conf-name>Proceedings of the 3rd IEEE International Conference on Mobile Ad-Hoc and Sensor Systems</conf-name>
<conf-loc>Vancouver, BC, Canada</conf-loc>
<conf-date>9–12 October 2006</conf-date>
<fpage>457</fpage>
<lpage>466</lpage>
</element-citation>
</ref>
<ref id="b31-sensors-12-15133"><label>31.</label>
<element-citation publication-type="confproc"><person-group person-group-type="author"><name><surname>Rustad</surname>
<given-names>H.</given-names>
</name>
</person-group>
<article-title>A Lightweight Protocol Suite for Underwater Communication</article-title>
<conf-name>Proceedings of the 2009 International Conference on Advanced Information Networking and Applications Workshops</conf-name>
<publisher-name>Bradford, UK</publisher-name>
<conf-date>26–29 May 2009</conf-date>
<fpage>1172</fpage>
<lpage>1178</lpage>
</element-citation>
</ref>
<ref id="b32-sensors-12-15133"><label>32.</label>
<element-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Dijkstra</surname>
<given-names>E.W.</given-names>
</name>
</person-group>
<article-title>A note on two problems in connexion with graphs</article-title>
<source>Numer. Math.</source>
<year>1959</year>
<volume>1</volume>
<fpage>269</fpage>
<lpage>271</lpage>
</element-citation>
</ref>
<ref id="b33-sensors-12-15133"><label>33.</label>
<element-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Abadi</surname>
<given-names>M.</given-names>
</name>
<name><surname>Needham</surname>
<given-names>R.</given-names>
</name>
</person-group>
<article-title>Prudent engineering practice for cryptographic protocols</article-title>
<source>IEEE Trans. Softw. Eng.</source>
<year>1996</year>
<volume>22</volume>
<fpage>6</fpage>
<lpage>15</lpage>
</element-citation>
</ref>
<ref id="b34-sensors-12-15133"><label>34.</label>
<element-citation publication-type="book"><person-group person-group-type="author"><name><surname>Barker</surname>
<given-names>E.B.</given-names>
</name>
<name><surname>Johnson</surname>
<given-names>D.</given-names>
</name>
<name><surname>Smid</surname>
<given-names>M.E.</given-names>
</name>
</person-group>
<source>Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography</source>
<comment>Technical Report</comment>
<publisher-name>National Institute of Standards and Technology (NIST)</publisher-name>
<publisher-loc>Gaithersburg, MD, USA</publisher-loc>
<year>2006</year>
</element-citation>
</ref>
<ref id="b35-sensors-12-15133"><label>35.</label>
<element-citation publication-type="confproc"><person-group person-group-type="author"><name><surname>Blundo</surname>
<given-names>C.</given-names>
</name>
<name><surname>Santis</surname>
<given-names>A.D.</given-names>
</name>
<name><surname>Herzberg</surname>
<given-names>A.</given-names>
</name>
<name><surname>Kutten</surname>
<given-names>S.</given-names>
</name>
<name><surname>Vaccaro</surname>
<given-names>U.</given-names>
</name>
<name><surname>Yung</surname>
<given-names>M.</given-names>
</name>
</person-group>
<article-title>Perfectly-Secure Key Distribution for Dynamic Conferences</article-title>
<conf-name>Proceedings of the 12th Annual International Cryptology Conference on Advances in Cryptology</conf-name>
<conf-loc>Santa Barbara, CA, USA</conf-loc>
<conf-date>22–26 August 1993</conf-date>
<fpage>471</fpage>
<lpage>486</lpage>
</element-citation>
</ref>
<ref id="b36-sensors-12-15133"><label>36.</label>
<element-citation publication-type="webpage"><article-title>The Folaga Vehicle</article-title>
<comment>Available online: <ext-link ext-link-type="uri" xlink:href="http://www.graaltech.it">http://www.graaltech.it</ext-link>
(accessed on 6 November 2012)</comment>
</element-citation>
</ref>
<ref id="b37-sensors-12-15133"><label>37.</label>
<element-citation publication-type="webpage"><article-title>The SimPy Simulator</article-title>
<comment>Available online: <ext-link ext-link-type="uri" xlink:href="http://simpy.sourceforge.net">http://simpy.sourceforge.net</ext-link>
(accessed on 6 November 2012)</comment>
</element-citation>
</ref>
<ref id="b38-sensors-12-15133"><label>38.</label>
<element-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Pompili</surname>
<given-names>D.</given-names>
</name>
<name><surname>Akyildiz</surname>
<given-names>I.</given-names>
</name>
</person-group>
<article-title>Overview of networking protocols for underwater wireless communications</article-title>
<source>Commun. Mag.</source>
<year>2009</year>
<volume>47</volume>
<fpage>97</fpage>
<lpage>102</lpage>
</element-citation>
</ref>
<ref id="b39-sensors-12-15133"><label>39.</label>
<element-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Lampson</surname>
<given-names>B.W.</given-names>
</name>
</person-group>
<article-title>Hints for computer system design</article-title>
<source>ACM Oper. Syst. Rev.</source>
<year>1983</year>
<volume>17</volume>
<fpage>33</fpage>
<lpage>48</lpage>
</element-citation>
</ref>
</ref-list>
</back>
<floats-group><fig id="f1-sensors-12-15133" position="float"><label>Figure 1.</label>
<caption><p>The surveillance network.</p>
</caption>
<graphic xlink:href="sensors-12-15133f1"></graphic>
</fig>
<fig id="f2-sensors-12-15133" position="float"><label>Figure 2.</label>
<caption><p>Implementation of the (<bold>a</bold>
) one-to-one and (<bold>b</bold>
) one-to-many communication paradigms.</p>
</caption>
<graphic xlink:href="sensors-12-15133f2"></graphic>
</fig>
<fig id="f3-sensors-12-15133" position="float"><label>Figure 3.</label>
<caption><p>Key chain.</p>
</caption>
<graphic xlink:href="sensors-12-15133f3"></graphic>
</fig>
<fig id="f4-sensors-12-15133" position="float"><label>Figure 4.</label>
<caption><p>Key tree.</p>
</caption>
<graphic xlink:href="sensors-12-15133f4"></graphic>
</fig>
<fig id="f5-sensors-12-15133" position="float"><label>Figure 5.</label>
<caption><p>An execution instance of FLOOD.</p>
</caption>
<graphic xlink:href="sensors-12-15133f5"></graphic>
</fig>
<fig id="f6-sensors-12-15133" position="float"><label>Figure 6.</label>
<caption><p>A DoS attack.</p>
</caption>
<graphic xlink:href="sensors-12-15133f6"></graphic>
</fig>
<fig id="f7-sensors-12-15133" position="float"><label>Figure 7.</label>
<caption><p>The CKDP applied to FLOOD.</p>
</caption>
<graphic xlink:href="sensors-12-15133f7"></graphic>
</fig>
<fig id="f8-sensors-12-15133" position="float"><label>Figure 8.</label>
<caption><p>The test-bed.</p>
</caption>
<graphic xlink:href="sensors-12-15133f8"></graphic>
</fig>
<fig id="f9-sensors-12-15133" position="float"><label>Figure 9.</label>
<caption><p>The nodes used in the experiments.</p>
</caption>
<graphic xlink:href="sensors-12-15133f9"></graphic>
</fig>
<fig id="f10-sensors-12-15133" position="float"><label>Figure 10.</label>
<caption><p>Average Delivery Ratio when security is enabled/disabled.</p>
</caption>
<graphic xlink:href="sensors-12-15133f10"></graphic>
</fig>
<fig id="f11-sensors-12-15133" position="float"><label>Figure 11.</label>
<caption><p>Average round-trip time when security is enabled/disabled.</p>
</caption>
<graphic xlink:href="sensors-12-15133f11"></graphic>
</fig>
<fig id="f12-sensors-12-15133" position="float"><label>Figure 12.</label>
<caption><p>(<bold>a</bold>
) Sparse Scenario; (<bold>b</bold>
) Dense Scenario.</p>
</caption>
<graphic xlink:href="sensors-12-15133f12"></graphic>
</fig>
<fig id="f13-sensors-12-15133" position="float"><label>Figure 13.</label>
<caption><p>Discovery Messages in Sparse and Dense Scenarios.</p>
</caption>
<graphic xlink:href="sensors-12-15133f13"></graphic>
</fig>
<fig id="f14-sensors-12-15133" position="float"><label>Figure 14.</label>
<caption><p>Discovery Bits, Add Bits and Del Bits in Sparse and Dense Scenarios.</p>
</caption>
<graphic xlink:href="sensors-12-15133f14"></graphic>
</fig>
<table-wrap id="t1-sensors-12-15133" position="float"><label>Table 1.</label>
<caption><p>Configuration parameters for Scenario L.</p>
</caption>
<table frame="box" rules="cols"><thead><tr><th align="left" valign="top" rowspan="1" colspan="1"><bold>Node</bold>
</th>
<th align="center" valign="top" rowspan="1" colspan="1"><bold>Distance from GW (m)</bold>
</th>
<th align="center" valign="top" rowspan="1" colspan="1"><bold>Depth (m)</bold>
</th>
</tr>
<tr><th valign="bottom" colspan="3" rowspan="1"><hr></hr>
</th>
</tr>
</thead>
<tbody><tr><td align="left" valign="top" rowspan="1" colspan="1">GW</td>
<td align="center" valign="top" rowspan="1" colspan="1">-</td>
<td align="center" valign="top" rowspan="1" colspan="1">90.3</td>
</tr>
<tr><td align="left" valign="top" rowspan="1" colspan="1">FN1</td>
<td align="center" valign="top" rowspan="1" colspan="1">163.5</td>
<td align="center" valign="top" rowspan="1" colspan="1">96</td>
</tr>
<tr><td align="left" valign="top" rowspan="1" colspan="1">FN2</td>
<td align="center" valign="top" rowspan="1" colspan="1">860</td>
<td align="center" valign="top" rowspan="1" colspan="1">39</td>
</tr>
<tr><td align="left" valign="top" rowspan="1" colspan="1">FLG1</td>
<td align="center" valign="top" rowspan="1" colspan="1">677.8</td>
<td align="center" valign="top" rowspan="1" colspan="1">20</td>
</tr>
<tr><td align="left" valign="top" rowspan="1" colspan="1">FLG2</td>
<td align="center" valign="top" rowspan="1" colspan="1">687.1</td>
<td align="center" valign="top" rowspan="1" colspan="1">15</td>
</tr>
</tbody>
</table>
</table-wrap>
<table-wrap id="t2-sensors-12-15133" position="float"><label>Table 2.</label>
<caption><p>Simulation parameters.</p>
</caption>
<table frame="box" rules="cols"><thead><tr><th align="left" valign="top" rowspan="1" colspan="1"><bold>Parameter</bold>
</th>
<th colspan="2" align="center" valign="top" rowspan="1"><bold>Value</bold>
</th>
</tr>
<tr><th valign="bottom" colspan="3" rowspan="1"><hr></hr>
</th>
</tr>
</thead>
<tbody><tr><td align="left" valign="top" rowspan="1" colspan="1">Duration</td>
<td colspan="2" align="center" valign="top" rowspan="1">5,000 s.</td>
</tr>
<tr><td align="left" valign="top" rowspan="1" colspan="1">Number of runs</td>
<td colspan="2" align="center" valign="top" rowspan="1">15</td>
</tr>
<tr><td align="left" valign="top" rowspan="1" colspan="1">Average transmission range</td>
<td colspan="2" align="center" valign="top" rowspan="1">2 km</td>
</tr>
<tr><td align="left" valign="top" rowspan="1" colspan="1">Maximum transmission power</td>
<td colspan="2" align="center" valign="top" rowspan="1">189 dB re <italic>μ</italic>
Pa</td>
</tr>
<tr><td align="left" valign="top" rowspan="1" colspan="1">Depth</td>
<td colspan="2" align="center" valign="top" rowspan="1">200 m</td>
</tr>
<tr><td align="left" valign="top" rowspan="1" colspan="1">Number of nodes</td>
<td colspan="2" align="center" valign="top" rowspan="1">9</td>
</tr>
<tr><td align="left" valign="top" rowspan="1" colspan="1">DIFS (silent period before transmission is considered)</td>
<td colspan="2" align="center" valign="top" rowspan="1">0.25 s</td>
</tr>
<tr><td align="left" valign="top" rowspan="1" colspan="1">SIFS (Wait time between DATA and ACK)</td>
<td colspan="2" align="center" valign="top" rowspan="1">0.01 s</td>
</tr>
<tr><td align="left" valign="top" rowspan="1" colspan="1">Max number of retransmissions</td>
<td colspan="2" align="center" valign="top" rowspan="1">7</td>
</tr>
<tr><td valign="bottom" colspan="3" rowspan="1"><hr></hr>
</td>
</tr>
<tr><td align="left" valign="top" rowspan="1" colspan="1"></td>
<td align="center" valign="top" rowspan="1" colspan="1"><bold>Sparse Scenario</bold>
</td>
<td align="center" valign="top" rowspan="1" colspan="1"><bold>Dense Scenario</bold>
</td>
</tr>
<tr><td valign="bottom" colspan="3" rowspan="1"><hr></hr>
</td>
</tr>
<tr><td align="left" valign="top" rowspan="1" colspan="1">Average number of Neighbors</td>
<td align="center" valign="top" rowspan="1" colspan="1">2</td>
<td align="center" valign="top" rowspan="1" colspan="1">5</td>
</tr>
</tbody>
</table>
</table-wrap>
</floats-group>
</pmc>
</record>
Pour manipuler ce document sous Unix (Dilib)
EXPLOR_STEP=$WICRI_ROOT/Ticri/CIDE/explor/TelematiV1/Data/Pmc/Corpus
HfdSelect -h $EXPLOR_STEP/biblio.hfd -nk 000566 | SxmlIndent | more
Ou
HfdSelect -h $EXPLOR_AREA/Data/Pmc/Corpus/biblio.hfd -nk 000566 | SxmlIndent | more
Pour mettre un lien sur cette page dans le réseau Wicri
{{Explor lien |wiki= Ticri/CIDE |area= TelematiV1 |flux= Pmc |étape= Corpus |type= RBID |clé= PMC:3522957 |texte= A Secure Communication Suite for Underwater Acoustic Sensor Networks }}
Pour générer des pages wiki
HfdIndexSelect -h $EXPLOR_AREA/Data/Pmc/Corpus/RBID.i -Sk "pubmed:23202204" \ | HfdSelect -Kh $EXPLOR_AREA/Data/Pmc/Corpus/biblio.hfd \ | NlmPubMed2Wicri -a TelematiV1
![]() | This area was generated with Dilib version V0.6.31. | ![]() |