| Literature DB >> 28009834 |
Walid Elgenaidi1,2, Thomas Newe3,4, Eoin O'Connell5,6, Daniel Toal7, Gerard Dooly8,9.
Abstract
There has been a significant increase in the proliferation and implementation of Wireless Sensor Networks (WSNs) in different disciplines, including the monitoring of maritime environments, healthcare systems, and industrial sectors. It has now become critical to address the security issues of data communication while considering sensor node constraints. There are many proposed schemes, including the scheme being proposed in this paper, to ensure that there is a high level of security in WSNs. This paper presents a symmetric security scheme for a maritime coastal environment monitoring WSN. The scheme provides security for travelling packets via individually encrypted links between authenticated neighbors, thus avoiding a reiteration of a global rekeying process. Furthermore, this scheme proposes a dynamic update key based on a trusted node configuration, called a leader node, which works as a trusted third party. The technique has been implemented in real time on a Waspmote test bed sensor platform and the results from both field testing and indoor bench testing environments are discussed in this paper.Entities:
Keywords: WSN; Waspmote; algorithm; dynamic symmetric key update; maritime WSN; security; wireless sensor networks
Year: 2016 PMID: 28009834 PMCID: PMC5191182 DOI: 10.3390/s16122204
Source DB: PubMed Journal: Sensors (Basel) ISSN: 1424-8220 Impact factor: 3.576
Figure 1Nodes in line topology.
Explanation of notation used in Figure 1.
| Symbol | Description |
|---|---|
| Ordinary nodes in the line topology | |
| Leader node | |
| { } | Symmetric encryption/decryption with key |
| Transmitted sensor data | |
| Secret encryption source key | |
| Secret encryption adjacent key of node | |
| Secret encryption individual key of node | |
| Secret encryption leader node key | |
| {{ | Sensor data encrypted with source and adjacent keys |
| { | Message encrypted with individual key of node |
| { | Message encrypted with leader nod key |
Figure 2Waspmote components, top and bottom sides.
Modules integrated in Waspmote.
| Module | Protocol | Frequency | Tx_Power | Sensitivity | Range |
|---|---|---|---|---|---|
| Xbee 802.14.5-pro | 802.14.5 | 2.4 GHz | 100 mW | −100 dBm | 7000 m |
| XBee ZBee-Pro | ZBee-Pro | 2.4 GHz | 50 mW | −102 dBm | 7000 m |
| XBee 868 | RF | 868 HMz | 315 mW | −112 dBm | 12 km |
| XBee 900 | RF | 900 MHz | 50 mW | −100 dBm | 10 km |
| WiFi | 802.11b/g | 2.4 GHz | 0–12 dBm | −83 dBm | 7000 m |
| GPRS | - | 8500/900/1800/1900 MHz | 2W(Class 4) 859/900 MHz | −109 dBm | km typical carrier range |
| 3G/GPRS | - | Tri-Band UMS 2100/1900/900 MHz | −106 dBm | km typical carrier range | |
| Bluetooth Low Energy | Bluetooth v.4.0/Bluetooth Smart | 2.4 GHz | −103 dBm | 100 m |
Figure 3ASCII Frame structure.
Figure 4Format of the encrypted frame.
Maximum frame size per protocol.
| Module | Maximum Frame Size | ||
|---|---|---|---|
| XBee-802.15.4 | Link Encrypted | @16bit Unicast | 98 Bytes |
| @64bit Unicast | 94 Bytes | ||
| Broadcast | 95 Bytes | ||
| Link Unencrypted | 100 Bytes | ||
| XBee-868 | 100 Bytes | ||
| XBee-900 | Link Encrypted | 80 Bytes | |
| Link Unencrypted | 100 Bytes | ||
| XBee-Digimesh | 73 Bytes | ||
| XBee-ZigBee | Link Encrypted | @64bit Unicast | 66 Bytes |
| Broadcast | 84 Bytes | ||
| Link Unencrypted | @64bit Unicast | 74 Bytes | |
| Broadcast | 92 Bytes | ||
| Bluetooth-transparent connection | Limited by MAX_FRAME | ||
| GPRS | Limited by MAX_FRAME | ||
| 3G | Limited by MAX_FRAME | ||
| LoRa/SX1272 | Limited by MAX_FRAME | ||
| WiFi | Limited by MAX_FRAME | ||
AES-128 with ECB cipher mode and zeros padding.
| Algorithm | Key Size | Data Block Size | Mode Cipher | Padding |
|---|---|---|---|---|
| AES-128 | 128 bits | 16 Bytes | ECB | ZEROS |
Figure 5Waspmote Frame on OSI stack for communication.
MD5 hash algorithm.
| Algorithm | Output Size (Bits) | Internal State Size (Bits) | Block Size (Bits) | Max Message Size (Bits) | Word Size (Bit) |
|---|---|---|---|---|---|
| MD5 | 128 | 128 | 512 | 264 − 1 | 32 |
Figure 6Network reconnection process.
Figure 7Keys administration.
Figure 8Waspmote platform integrated with XBee-pro module.
Figure 9System outdoor deployment.
Figure 10Average RSSI in three different scenarios of outdoor implementation.
Figure 11Measurements of RTT in three different scenarios at three different distances.
Figure 12Fully operational average current consumption.
Figure 13Average current consumption of sleeping mode phase.
Measured current consumption of scheme modes.
| Scheme Mode | Measured Current Consumption (mA) | ||
|---|---|---|---|
| Max | Min | Average | |
| Fully functional system | 66.732 | 63.5297 | 64.9123 |
| XBee module (sleeping) | 9.4567 | 5.6248 | 7.4355 |
| XBee module current consumption (awake) | 57.2753 | 57.9049 | 57.4768 |
Figure 14Proposed scheme measured RSSI values with different distances versus the Piyare [19] results.
Figure 15Multi-hop measurement of average round trip time [12].
Figure 16Multi-repeaters round trip time measurement result.
Comparison between schemes.
| Scheme | Offline Phase | Cryptographic Scheme | Key Size (bits) | Communication Type | Number of Storage Keys | Memory Space Used by the Scheme | Re-Keying Strategy |
|---|---|---|---|---|---|---|---|
| Neighborhood Scheme [ | Certificate stored in each node | Hybrid (RSA and symmetric) | 128 | Multicast/Unicast | Each node stores: own public/private keys; own secret neighborhood key; neighbors secret key(s), and source key (used when the node is data source) | Not Given | Local operation, where each node updates keys with its current neighbor. |
| Hierarchical Key Management Scheme [ | No pre-loaded keys | Hybrid (D–H and Symmetric) | Not Given | Broadcast (2-hop adjacent node) | Level 1 head stores its secret key and secret key of Level 2 head. Level 2 head stores its secret key and secret key of Level 1 head. Ordinary node stores the secret key of the Level 2 head, secret communication key, and DH keys. | Not Given | Complicated operation where each level head node must regenerate a number of keys. |
| Time-Based Key Management Scheme [ | Keys pre-loaded | Symmetric | 64 | Broadcast | 500 keys in center node. 100 keys for sensor nodes (to ensure sharing of a key with at least one of 10 neighbors) | 4 KB for center node 0.8 KB for sensor node | Only the nodes deployed at the same time when compromised node is revoked have to regenerate keys. |
| Presented Scheme | Keys pre-loaded | Symmetric AES-128 in ECB mode with zeros padding. Key generation -MD5 and RTC. | 128 | Unicast | (5 keys) Each ordinary node stores; own adjacent key; neighbor shared adjacent key; an individual key that is shared with leader node; Leader node master key, and a source key (used when the node is data source). | Program size 57,230 bytes Ram required 4987 bytes. | Re-keying in this scheme is a local operation, where only one node must update its adjacent key, in addition to the leader node key. |
Comparison between schemes.
| Scheme | Implementation Environment | Node Coordination | Comments |
|---|---|---|---|
| Neighborhood Scheme [ | Simulation using the Glomosim Simulator. Used HP iPAQ 550 PDAs outdoors. | Node authentication is performed without coordination with other nodes. | Provides protection against attacks to the routing protocol using X509, RSA and a sequence number. Rekeying is a local operation between the nodes that share neighborhood keys with a revoked node. Provides forward and backward security. Does not rely on an online trusted third party. |
| Hierarchical Key Management Scheme [ | Simulation only | Level 1 head coordinates all Level 2 heads in its subgroup. Level 2 head coordinates all ordinary heads in its subgroup. | Uses a spanning tree topology in ad hoc networks. Provides the forward and backward security. Latency issues during the authentication process and updating secret keys. |
| Time-Based Key Management Scheme [ | Simulation only | For additional node deployment a centre node coordinates the authentication. | The scheme is not suitable for a large sensor network because of key storage requirements. Offers protection against wormhole and sinkhole attack. Provides forward and backward security. |
| Presented Scheme | Waspmote nodes and Gateway, XBee 802.15.4 Pro module with antenna. MC1322x USB ZigBee dongle. Agilent 66321D Mobile DC Source. Waspmote Pro IDE v04 with Pro API v013 software based on Arduino. X-CTU provided by Digi and the Wireshark network analyzer in an outdoor implementation. | The Leader node monitors the behaviour of all ordinary nodes in this scheme. It is responsible for the authentication, revocation, and reconfiguration phases of other nodes. | Provides protection against attacks to the routing protocol using location based routing. Node addition or revocation is handled by the Leader Node. Rekeying is a local operation between the nodes that share neighborhood keys with a revoked node. Provides forward and backward security. Does not rely on online trusted third party. All message exchanges are acknowledged. |