Abstract

A network reprogramming protocol is made for updating the firmware of a wireless sensor network (WSN) in situ. For security reasons, every firmware update must be authenticated to prevent an attacker from installing its code in the network.While existing schemes can provide authentication services, they are insufficient for a new generation of network coding-based reprogramming protocols like Rateless Deluge. We propose Secure Rateless Deluge or Sreluge, a secure version of Rateless Deluge that is resistant to pollution attacks (denial-of-service attacks aimed at polluting encoded packets). Sreluge employs a neighbor classification system and a time series forecasting technique to isolate polluters, and a combinatorial technique to decode data packets in the presence of polluters before the isolation is complete. For detecting polluters, Sreluge has zero false negative rate and a negligible false positive rate. TOSSIM simulations and experimental results show that Sreluge is practical.

Highlights

  • There are occasions when new applications need to be installed, or when existing applications need to be modified or patched in a wireless sensor network (WSN)

  • In the core of a secure network, reprogramming protocol is a data dissemination protocol that distributes the new firmware to all the nodes in the network in an energy-efficient manner

  • The base station broadcasts a command (CMD) globally to announce the availability of the new firmware

Read more

Summary

Introduction

There are occasions when new applications need to be installed, or when existing applications need to be modified or patched in a WSN. In the core of a secure network, reprogramming protocol ( known as secure code update or secure code distribution in the literature) is a data dissemination protocol that distributes the new firmware to all the nodes in the network in an energy-efficient manner. After successfully collecting all the pages, a node’s action depends on the semantics of CMD. If the CMD is “disseminate,” the node’s job is done; if the CMD is “disseminate and reboot,” the node reboots using the new firmware (these are two existing commands in TinyOS 2.x). The problem of securing the protocol boils down to authenticating the CMD, ADV, REQ, and data packets, and addressing the threat of denialof-service (DoS) attacks in every step of the protocol. We are primarily concerned with the authentication of data packets and the mitigation of DoS attacks during the process

Methods
Results
Conclusion
Full Text
Published version (Free)

Talk to us

Join us for a 30 min session where you can share your feedback and ask us any queries you have

Schedule a call