Engineering

A lightweight secure scheme for detecting provenance forgery and packet drop attacks

Description
1. A Lightweight Secure Scheme for Detecting Provenance Forgery and Packet Drop Attacks in Wireless Sensor Networks Salmin Sultana, Gabriel Ghinita, Member, IEEE , Elisa…
Categories
Published
of 14
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
Share
Transcript
  • 1. A Lightweight Secure Scheme for Detecting Provenance Forgery and Packet Drop Attacks in Wireless Sensor Networks Salmin Sultana, Gabriel Ghinita, Member, IEEE , Elisa Bertino, Fellow, IEEE , and Mohamed Shehab, Member, IEEE Computer Society Abstract—Large-scale sensor networks are deployed in numerous application domains, and the data they collect are used in decision- making for critical infrastructures. Data are streamed from multiple sources through intermediate processing nodes that aggregate information. A malicious adversary may introduce additional nodes in the network or compromise existing ones. Therefore, assuring high data trustworthiness is crucial for correct decision-making. Data provenance represents a key factor in evaluating the trustworthiness of sensor data. Provenance management for sensor networks introduces several challenging requirements, such as low energy and bandwidth consumption, efficient storage and secure transmission. In this paper, we propose a novel lightweight scheme to securely transmit provenance for sensor data. The proposed technique relies on in-packet Bloom filters to encode provenance. We introduce efficient mechanisms for provenance verification and reconstruction at the base station. In addition, we extend the secure provenance scheme with functionality to detect packet drop attacks staged by malicious data forwarding nodes. We evaluate the proposed technique both analytically and empirically, and the results prove the effectiveness and efficiency of the lightweight secure provenance scheme in detecting packet forgery and loss attacks. Index Terms—Provenance, security, sensor networks Ç 1 INTRODUCTION SENSOR networks are used in numerous application domains, such as cyberphysical infrastructure systems, environmental monitoring, power grids, etc. Data are pro- duced at a large number of sensor node sources and proc- essed in-network at intermediate hops on their way to a base station (BS) that performs decision-making. The diver- sity of data sources creates the need to assure the trustwor- thiness of data, such that only trustworthy information is considered in the decision process. Data provenance is an effective method to assess data trustworthiness, since it summarizes the history of ownership and the actions per- formed on the data. Recent research [1] highlighted the key contribution of provenance in systems where the use of untrustworthy data may lead to catastrophic failures (e. g., SCADA systems). Although provenance modeling, col- lection, and querying have been studied extensively for workflows and curated databases [2], [3], provenance in sensor networks has not been properly addressed. We investigate the problem of secure and efficient provenance transmission and processing for sensor networks, and we use provenance to detect packet loss attacks staged by malicious sensor nodes. In a multi-hop sensor network, data provenance allows the BS to trace the source and forwarding path of an individual data packet. Provenance must be recorded for each packet, but important challenges arise due to the tight storage, energy and bandwidth constraints of sensor nodes. Therefore, it is necessary to devise a light-weight prove- nance solution with low overhead. Furthermore, sensors often operate in an untrusted environment, where they may be subject to attacks. Hence, it is necessary to address secu- rity requirements such as confidentiality, integrity and fresh- ness of provenance. Our goal is to design a provenance encoding and decoding mechanism that satisfies such security and performance needs. We propose a provenance encod- ing strategy whereby each node on the path of a data packet securely embeds provenance information within a Bloom fil- ter (BF) that is transmitted along with the data. Upon receiv- ing the packet, the BS extracts and verifies the provenance information. We also devise an extension of the provenance encoding scheme that allows the BS to detect if a packet drop attack was staged by a malicious node. As opposed to existing research that employs separate transmission channels for data and provenance [4], we only require a single channel for both. Furthermore, tradi- tional provenance security solutions use intensively cryp- tography and digital signatures [5], and they employ append-based data structures to store provenance, lead- ing to prohibitive costs. In contrast, we use only fast mes- sage authentication code (MAC) schemes and Bloom filters, which are fixed-size data structures that compactly represent provenance. Bloom filters make efficient usage S. Sultana is with the Department of Electrical and Computer Engineer- ing, Purdue University. E-mail: ssultana@purdue.edu. G. Ghinita is with the Department of Computer Science, University of Massachusetts, Boston. E-mail: Gabriel.Ghinita@umb.edu. E. Bertino is with the Department of Computer Sciences, Purdue University. E-mail: bertino@purdue.edu. M. Shehab is with the Department of Software and Information Systems, University of North Carolina at Charlotte. E-mail: mshehab@uncc.edu. Manuscript received 15 Feb. 2013; revised 12 Sept. 2013; accepted 21 Sept. 2013. Date of publication 7 Oct. 2013; date of current version 15 May 2015. For information on obtaining reprints of this article, please send e-mail to: reprints@ieee.org, and reference the Digital Object Identifier below. Digital Object Identifier no. 10.1109/TDSC.2013.44 256 IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 12, NO. 3, MAY/JUNE 2015 1545-5971 ß 2013 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information. For More Details Contact G.Venkat Rao PVR TECHNOLOGIES 8143271457
  • 2. of bandwidth, and they yield low error rates in practice. Our specific contributions are: We formulate the problem of secure provenance transmission in sensor networks, and identify the challenges specific to this context. We propose an in-packet Bloom filter (iBF) prove- nance-encoding scheme. We design efficient techniques for provenance decoding and verification at the base station. We extend the secure provenance encoding scheme and devise a mechanism that detects packet drop attacks staged by malicious forwarding sensor nodes. We perform a detailed security analysis and perfor- mance evaluation of the proposed provenance encod- ing scheme and packet loss detection mechanism. The rest of the paper is organized as follows: Section 2 sets the problem background and describes the system, threat and security models. Section 3 introduces the provenance encoding scheme, whereas Section 4 outlines the scheme extension and the mechanism for identification of malicious nodes that stage packet drop attacks. Section 5 presents the security analysis of our methods. Section 6 provides an ana- lytical performance evaluation, whereas Section 7 presents the experimental evaluation results for the proposed scheme. We survey related work in Section 8 and conclude with directions for future research in Section 9. 2 BACKGROUND AND SYSTEM MODEL In this section, we introduce the network, data and prove- nance models used. We also present the threat model and security requirements. Finally, we provide a brief primer on Bloom filters, their fundamental properties and operations. 2.1 Network Model We consider a multihop wireless sensor network, consisting of a number of sensor nodes and a base station that collects data from the network. The network is modeled as a graph GðN; LÞ, where N ¼ fnij; 1 i jNjg is the set of nodes, and L is the set of links, containing an element li;j for each pair of nodes ni and nj that are communicating directly with each other. Sensor nodes are stationary after deploy- ment, but routing paths may change over time, e.g., due to node failure. Each node reports its neighboring (i.e., one hop) node information to the BS after deployment. The BS assigns each node a unique identifier nodeID and a symmet- ric cryptographic key Ki. In addition, a set of hash functions H ¼ fh1; h2; . . . ; hkg are broadcast to the nodes for use dur- ing provenance embedding. 2.2 Data Model We assume a multiple-round process of data collection. Each sensor generates data periodically, and individual val- ues are aggregated towards the BS using any existing hier- archical (i.e., tree-based) dissemination scheme [6]. A data path of D hops is represented as nl; n1; n2; . . . ; nD , where nl is a leaf node representing the data source, and node ni is i hops away from nl. Each non-leaf node in the path aggregates the received data and provenance with its own locally-generated data and provenance. Each data packet contains 1) a unique packet sequence number, 2) a data value, and 3) provenance. The sequence number is attached to the packet by the data source, and all nodes use the same sequence number for a given round [7]. The sequence number integrity is ensured through MACs, as discussed in Section 3. 2.3 Provenance Model We consider node-level provenance, which encodes the nodes at each step of data processing. This representation has been used in previous research for trust management [1] and for detecting selective forwarding attacks [8]. Given packet d, its provenance is modeled as a directed acyclic graph GðV; EÞ where each vertex v 2 V is attributed to a specific node HOSTðvÞ ¼ n and represents the provenance record (i.e., nodeID) for that node. Each vertex in the prove- nance graph is uniquely identified by a vertex ID (VID) which is generated by the host node using cryptographic hash functions. The edge set E consists of directed edges that connect sensor nodes. Definition 1 (Provenance). Given a data packet d, the prove- nance pd is a directed acyclic graph GðV; EÞ satisfying the following properties: 1) pd is a subgraph of the sensor network GðN; LÞ; 2) for vi; vj 2 V , vi is a child of vj if and only if HOST ðviÞ ¼ ni participated in the distributed cal- culation of d and/or forwarded the data to HOST (vj) =nj; 3) for a set U ¼ fvig V and vj 2 V , U is a set of chil- dren of vj if and only if HOST (vj) collects processed/for- warded data from each HOST(vi 2 U) to generate the aggregated result. Fig. 1 shows two provenance examples. In Fig. 1a, the leaf node nl generates a data packet d, and each intermedi- ate node aggregates its own sensory data with d and then forwards it towards the BS. Hence, the provenance corre- sponding to d is vl; v1; v2; v3 , which can be represented as a simple path. In Fig. 1b, the internal node n1 generates the data d by aggregating data d1; . . . ; d4 from nl1 ; . . . ; nl4 and then passes d towards the BS. Here, n1 is an aggregator and the aggregated provenance fvl1 ; vl2 ; vl3 ; vl4 g; v1; v2; v3 is represented as a tree. 2.4 Threat Model and Security Objectives We assume that the BS is trusted, but any other arbitrary node may be malicious. An adversary can eavesdrop and Fig. 1. Provenance graph for a sensor network. SULTANA ET AL.: A LIGHTWEIGHT SECURE SCHEME FOR DETECTING PROVENANCE FORGERY AND PACKET DROP ATTACKS IN WIRELESS... 257 For More Details Contact G.Venkat Rao PVR TECHNOLOGIES 8143271457
  • 3. perform traffic analysis anywhere on the path. In addition, the adversary is able to deploy a few malicious nodes, as well as compromise a few legitimate nodes by capturing them and physically overwriting their memory. If an adver- sary compromises a node, it can extract all key materials, data, and codes stored on that node. The adversary may drop, inject or alter packets on the links that are under its control. We do not consider denial of service attacks such as the complete removal of provenance, since a data packet with no provenance records will make the data highly sus- picious [5] and hence generate an alarm at the BS. Instead, the primary concern is that an attacker attempts to misrep- resent the data provenance. Our objective is to achieve the following security properties: Confidentiality. An adversary cannot gain any knowledge about data provenance by analyzing the contents of a packet. Only authorized parties (e.g., the BS) can process and check the integrity of provenance. Integrity. An adversary, acting alone or colluding with others, cannot add or remove non-colluding nodes from the provenance of benign data (i.e., data generated by benign nodes) without being detected. Freshness. An adversary cannot replay captured data and provenance without being detected by the BS. It is also important to provide Data-Provenance Binding, i. e., a coupling between data and provenance so that an attacker cannot successfully drop or alter the legitimate data while retaining the provenance, or swap the prove- nance of two packets. Although this problem is orthogonal to the method we propose, we address it in Section 3.3. 2.5 The Bloom Filter The BF is a space-efficient data structure for probabilistic representation of a set of items S = fs1; s2; . . . ; sng using an array of m bits with k independent hash functions h1; h2; . . . ; hk. The output of each hash function hi maps an item s uniformly to the range [0, m À 1], i.e., an index in a m-bit array. The BF can be represented as fb0; . . . ; bmÀ1g. Initially all m bits are set to 0. To insert an element s 2 S into a BF, s is hashed with all the k hash functions producing the values hiðsÞð1 i kÞ. The bits corresponding to these values are then set to 1 in the bit array. Fig. 2 illustrates an example of BF insertion. To query the membership of an item s0 within S, the bits at indices hiðs0 Þð1 i kÞ are checked. If any of them is 0, then certainly s0 62 S. Otherwise, if all of the bits are set to 1, s0 2 S with high probability. There exists a possibility of error which arises due to hashing collision that makes the elements in S collectively causing indices hiðs0 Þ being set to 1 even if s0 62 S. This is called a false positive. Note that, there is no false negative in the BF membership verification. Several BF variations that provide additional functional- ity exist. A counting bloom filter (CBF) [9] associates a small counter with every bit, which is incremented/decremented upon item insertion/deletion. To answer approximate set membership queries, the distance-sensitive Bloom filter [10] has been proposed. However, aggregation is the only opera- tion needed in our problem setting. The cumulative nature of the basic BF construction inherently supports the aggrega- tion of BFs of a same kind, so we do not require CBFs or other BF variants. 3 SECURE PROVENANCE ENCODING We propose a distributed mechanism to encode provenance at the nodes and a centralized algorithm to decode it at the BS. The technical core of our proposal is the notion of in- packet Bloom filter [11]. Each packet consists of a unique sequence number, data value, and an iBF which holds the provenance. We emphasize that our focus is on securely transmitting provenance to the BS. In an aggregation infra- structure, securing the data values is also an important aspect, but that has been already addressed in previous work (e.g., [12]). Our secure provenance technique can be used in conjunction with such work to obtain a complete solution that provides security for data, provenance and data-provenance binding, as shown in Section 3.3. 3.1 Provenance Encoding For a data packet, provenance encoding refers to generating the vertices in the provenance graph and inserting them into the iBF. Each vertex originates at a node in the data path and represents the provenance record of the host node. A vertex is uniquely identified by the vertex ID. The VID is generated per-packet based on the packet sequence number (seq) and the secret key Ki of the host node. We use a block cipher function to produce this VID in a secure manner. Thus for a given data packet, the VID of a vertex representing the node ni is computed as vidi ¼ generateVIDðni; seqÞ ¼ EKi ðseqÞ; (1) where E is a secure block cipher such as AES, etc. When a source node generates a packet, it also creates a BF (referred to as ibf0), initialized to 0. The source then gen- erates a vertex according to Eq. (1), inserts the VID into ibf0 and transmits the BF as a part of the packet. Upon receiving the packet, each intermediate node nj performs data as well as provenance aggregation. If nj receives data from a single child njÀ1, it aggregates the partial provenance contained in the packet with its own provenance record. In this case, the iBF ibfjÀ1 belonging to the received packet represents a partial provenance, i.e., the provenance graph of the sub-path from the source up to njÀ1. On the other hand, if nj has more than one child, it generates an aggregated provenance from its own prove- nance record and the partial provenance received from its child nodes. At first, nj computes a BF ibfjÀ1 by bitwise-O- Ring the iBFs from its children. ibfjÀ1 represents a partial Fig. 2. A Bloom filter with n ¼ 4, m ¼ 16 and k ¼ 3. 258 IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 12, NO. 3, MAY/JUNE 2015 For More Details Contact G.Venkat Rao PVR TECHNOLOGIES 8143271457
  • 4. aggregated provenance from all of the children. In either case, the ultimate aggregated provenance is generated by encoding the provenance record of nj into ibfjÀ1. To this end, nj creates a vertex using Eq. (1) and inserts the VID into ibfjÀ1 which is then referred to as ibfj. When the packet reaches the BS, the iBF contains the provenance records of all the nodes in the path i.e. the full provenance. We denote this final record by ibf. Example. We illustrate the encoding mechanism in Fig. 3a. The data path considered is 1; 4; 7 , where node 1 is the data source. We use a 10-bit BF and a set of three hash functions H ¼ fh1; h2; h3g for BF operations. When node 1 generates a data packet with sequence number seq, it cre- ates the BF ibf0 which is set to all 0’s. The node then cre- ates a vertex corresponding to its provenance record and computes the VID as vid1 ¼ EK1 ðseqÞ. To insert vid1 into ibf0, node 1 generates three indices as h1ðvid1Þ ¼ 1, h2ðvid1Þ ¼ 3, h3ðvid1Þ ¼ 8. The VID is then inserted by set- ting ibf0½1Š, ibf0½3Š, and ibf0½8Š to 1. The updated ibf0 along with the packet is then sent towards the BS. Upon receiving the packet, node 4 performs provenance aggregation. Since the node has one child, it only aggregates its own provenance record with ibf0. For this purpose, the node generates a VID vid4; computes 3 indices as h1ðvid4Þ ¼ 3, h2ðvid4Þ ¼ 6, h3ðvid4Þ ¼ 9; and inserts vid4 into ibf0 by setting bits 3, 6, 9 of the iBF to 1. This updated iBF is referred to as ibf1. The data packet with ibf1 is then for- warded to node 7 which repeats the provenance aggregation steps. At the end, the BS receives the packet with the final iBF (ibf2 from node 7) and stores this iBF for further processing. 3.2 Provenance Decoding When the BS receives a data packet, it executes the prove- nance verification process, which assumes that the BS knows what the data path should be, and checks the iBF to see whether the correct path has been followed. However, right after network deployment, as well as when the topology changes (e.g., due to node failure), the path of a packet sent by a source may not be known to the BS. In this case, a prove- nance collection process is necessary, which retrieves prove- nance from the received iBF and thus the BS learns the data path from a source node. Afterwards, upon receiving a packet, it is sufficient for the BS to verify its knowledge of provenance with that encoded in the packet. Below we dis- cuss these processes in detail: Provenance verification. The BS conducts the verification process not only to verify its knowledge of provenance but also to check the integrity of the transmitted provenance. Algorithm 1 shows the steps to verify provenance for a given packet. We assume that the knowledge of the BS about this packet’s path is P0 . At first, th
  • Search
    Related Search
    We Need Your Support
    Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

    Thanks to everyone for your continued support.

    No, Thanks