An Enhanced Scheme to Defend against False-Endorsement-Based DoS Attacks in WSNs

IEEE International Conference on Wireless & Mobile Computing, Networking & Communication An Enhanced Scheme to Defend against False-Endorsement-Based DoS Attacks in WSNs Christoph Krauß, Markus Schneider, and Claudia Eckert Technische Universität Darmstadt, Darmstadt, Germany, {krauss, eckert}@sec.informatik.tu-darmstadt.de Fraunhofer Institute for Secure Information Technology (SIT), Darmstadt, Germany, markus.schneider@sit.fraunhofer.de Abstract Node compromise is a serious threat in wireless sensor networks, as it enables an adversary to perform various attacks. Many security schemes exploit the redundancy of many wireless sensor networks to mitigate the impact of node compromise. A report for the base station, generated by one node, must be endorsed by multiple neighboring sensor nodes. However, already proposed schemes are susceptible to False-Endorsement- Based Denial of Service attacks, where a compromised node sends a false endorsement that invalidates the collaboratively generated report. A formerly proposed scheme addresses such an attack, thereby enabling the detection and exclusion of false endorsing nodes. However, a jamming attack can result in a false exclusion of non-compromised nodes. In this paper, we discuss possible solutions to prevent false exclusions of non-compromised nodes and propose an extended scheme. Index Terms Wireless Sensor Networks, Security, Node Compromise, Denial-of-Service Attacks, Report Generation I. INTRODUCTION It is expected that wireless sensor networks (WSNs) [1] will be deployed in many security- and safety-critical applications, such as military surveillance, or medical applications such as patient health monitoring. Thus, securing sensor networks is of paramount importance. However, since the resources of the sensor nodes are severely constrained, and sensor nodes may be deployed in an unattended or even hostile environment, this is a challenging task. An adversary may compromise a sensor node to access all data stored on the node (e.g., cryptographic keys) and perform insider attacks, e.g., inject false data to cause false alarms. Likewise, he can inject numerous false messages to waste the scarce energy resources of the forwarding nodes that send the data through multi-hop communication to the base station, called sink. This attack is called Path-based Denial of Service (PDoS) attack [2]. Several schemes (e.g., [3], [4], [5], [6], [7], [8], [9]) have been proposed to cope with false data injection and PDoS attacks. One commonly used approach to mitigate the impact of node compromise is exploiting redundancy. Multiple sensor nodes collaboratively generate a report. One node initiates the report generation and neighboring nodes generate an endorsement for the report if they agree on it by, e.g., generating a Message Authentication Code (MAC) on the report using a shared key with the sink. However, these schemes are susceptible to False-Endorsement-Based Denial of Service (FEDoS) attacks [10]. In a FEDoS attack an adversary who has compromised only a single node can invalidate the collaboratively generated message by simply sending a false endorsement, e.g., a wrong MAC value that cannot be verified by the report generating node. Since most of these schemes compress the endorsements, the sink is also not able to detect a false endorsement. Thus, the sink cannot distinguish between a FEDoS attack or if the report generating node has tried to perform a false data injection attack. In [10], a scheme is proposed that addresses FEDoS attacks. The scheme can be used to extend schemes such as [4], [7], [8], [9] to handle all three types of attacks: (1) false data injection (to deceive the sink), (2) PDoS, and (3) FEDoS attacks. This scheme relies on efficient symmetric cryptography and enables the report generating node to verify that a neighboring node has sent a false endorsement. Therefore, an endorsing node has to prove at a later point in time, that the sent endorsement was correct. If the proof fails or a node does not perform the proof, the node is locally excluded by the report generating node. In [10], an adversary performing a jamming attack is not considered. Using an RF source, an adversary may broadcast energy on the spectrum of the wireless channel in order to disrupt signal reception. Thus, the adversary can either disrupt the reception of endorsements or jam the wireless channel at the time when a node performs the proof. The latter case results in a false exclusion of a node. In this paper, we address the jamming attack to falsely exclude nodes. We discuss several possible solutions and extend the scheme presented in [10] to address this attack. For this, we introduce a greylisting approach. If the report generating node does not receive the proof of an endorsing node, either an active attacker might have performed a jamming attack or the endorsing node indeed did not perform the proof. Thus, the report generating node does not immediately exclude this node, but rather greylists the node. The node is able to perform the proof within the next endorsement it sends when no jamming attack occurs. The enhancement introduces only a marginal increase of energy consumption compared to the original scheme. The paper is organized as follows: In section II related work is presented. The original protocol is briefly introduced in section III. In section IV, we discuss possible solutions to the jamming attack on the original protocol and present an enhanced scheme that is not susceptible to this attack. We 978-0-7695-3393-3/08 $25.00 2008 IEEE DOI 10.1109/WiMob.2008.13 586

analyze the enhanced scheme in section V, and conclude the paper in section VI. II. RELATED WORK In [9], the STEF scheme addressing PDoS attacks is introduced. Furthermore, a comprehensive overview of other different approaches [3], [4], [6], [11], [12], [2], [7], [8] to handle PDoS attacks is presented. However, all these schemes do not consider FEDoS attacks. The first work considering FEDoS attacks is a probabilistic voting-based filtering scheme [5]. However, this scheme is a special extension for the scheme presented in [3] and cannot be used to extend schemes such as [4], [7], [8], [9]. Krauß et al. [10] propose a scheme that enables a collaborative report generation addressing false data injection, PDoS, and FEDoS attacks. To address FEDoS attacks, the scheme requires that each node that has endorsed a report, must prove at a later point in time that the previously sent endorsement was correct. If the proof fails, or a node does not performs the proof, this node is locally excluded by the node that initiated the report generation. However, if an adversary is jamming the wireless channel exactly at the time a node tries to perform the proof, this node is falsely excluded. To additionally address PDoS attacks, the scheme can be used in conjunction with, e.g., the STEF scheme [9]. Jamming attacks in WSNs have been investigated in the literature (e.g., [13], [14]). The presented mechanisms include detection of jamming attacks, retreat from the jammer (e.g., through channel surfing or spatial retreats), or trying to achieve communication even in the presence of the jammer. However, these mechanisms are often not reliable and work only under certain assumptions. III. ORIGINAL SCHEME The original scheme [10] assumes a cluster structure of the network. The cluster head (CH) initiates the report generation and t of its u cluster nodes CN j, j =1,...,u must endorse the report. t is a system parameter and can be adjusted according to the density of the network, the resistance to node compromise, etc. All nodes are of similar type, e.g., comparable to the Berkeley MICA2 motes [15], severely resource constrained and are only able to perform symmetric cryptography. However, it is assumed that the sink is not constrained in its resources, but possesses all keying material shared with the sensor nodes, and is not compromised. The main idea is that a cluster node (CN) generates an endorsement for a report by using values of a hash chain. These values are only valid in a certain time interval I and are disclosed at a later point in time. Therefore, the nodes are loosely time synchronized as in μtesla [16]. CH is able to verify the already received and used endorsements when these hash values are disclosed, and furthermore, a malicious CH cannot misuse these values to generate endorsements for arbitrary reports, since the hash values are invalid at the time of disclosure. The scheme is divided into three phases: (1) Bootstrapping, (2) Report Generation, and (3) Verification. The bootstrapping phase is performed to configure the sensor nodes before deployment and to execute some initialization procedures directly after deployment. It is performed only once and assumed to be secure, i.e., nodes cannot be compromised. CH and CN 1,...,CN u are assigned a unique identifier ID CH and ID CN1,...,ID CNu, and are preloaded with a hash chain C CH and C CN1,...,C CNu. A hash chain C = c 0,...,c n is generated by applying a hash function h : {0, 1} l {0, 1} l successively on a seed value c n, such that c ν = h(c ν+1 ), with ν = n 1,n 2,...,1, 0. After deployment, each sensor node exchanges the initial verification values c CH 0 and c CN1 0,...,c CNu 0, respectively. Furthermore, each pair of neighboring nodes establishes a pairwise key using some existing schemes to ensure the authenticity and integrity of the exchanged messages between neighboring nodes and that replayed messages are detected. The report generation phase is initiated by CH performing the initial measurement of a physical phenomena. CH generates the related report R and associates the time of measurement T M with it. R and T M are broadcasted to all CN j in the cluster. Each CN j checks the interval of validity of T M, by verifying that the measurement has been performed in the current interval I ; it then verifies that R matches its own measurement within a certain error range ε. Those CN i where the verifications pass, generate an endorsement by calculating End CNi = h(c CNi R T M ) and send it to CH. The hash value c CNi is only valid in interval I for node CN i. CH stores all received endorsements for future verification purposes. CH calculates End CH = h(c CH R T M ), chooses t endorsements received from its CNs, and compresses them using bitwise XOR to one SEnd. Finally, CH sends the message containing R, T M, SEnd, and the node identifiers of itself and the t endorsing nodes to the sink at time T S. The verification phase is twofold. When the sink receives the message generated by CH, it verifies that CH and t CNs have collaboratively generated the report. This prevents an adversary who compromises less than t +1 nodes from performing a successful false data injection attack to deceive the sink. At the time when CNs disclose the hash chain values used to generate an endorsement, CH verifies if a FEDoS attack has been performed in the report generation phase. The sink receives the message from CH at time T R.It first verifies that the received message contains t +1 node identifiers. Next, it checks whether the used hash chain values have not been disclosed yet by verifying if T R + T δ <T, where T δ is the maximum synchronization error and T is the time when the hash chain values used in interval I are disclosed. Since it is assumed that the sink is not limited in its resources, it stores all hash values of each node s hash chain. Thus, the sink calculates SEnd using the locally stored hash chain values and compares the result with the received SEnd. If all verifications pass, the report is accepted. The sink is not able to distinguish whether a compromised CN has sent a false endorsement or a compromised CH has tried to perform a false data injection attack by guessing some endorsements. In contrast, however, CH is able to verify the 587

T M T S T R I 1 I 2 I 3 I 4 Interval... Hash value c 1 c 2 c 3 c 4... used T 1 T 2 T 3 Fig. 1. Example: An adversary performs a jamming attack at time T 1. received endorsements and to detect false endorsing CNs. The second verification is performed by CH when the endorsing CNs disclose their used hash chain values c CNi to CH. The values are disclosed at time T =(+Δ) T L, where T L denotes the length of an interval and Δ specifies the delay before the hash chain values are disclosed. First, CH checks that the hash chain value is valid by calculating h(c CNi )= c CNi 1. Next, it recomputes End CN i = h(c CNi R T M ) using the disclosed hash chain value. CH then compares End with the stored endorsement End. If the verifications pass, the sent endorsement from CN was correct. Whenever one of the verifications fails, CH excludes this CN from any further report generation. In the case that a CN does not disclose the hash chain value, CH also excludes this node. In the latter case, an adversary performing a jamming attack can get CH to falsely exclude an innocent CN. The following example illustrates this. Consider the chronological order shown in Figure 1. A report has been generated and endorsed in interval I 1. Thus, all non-compromised CN i that have sent an endorsement, disclose the used hash chain values c CNi 1 at time T 1.IfCH does not receive the hash chain value of a CN, it excludes this CN from any further report generation. Thus, an adversary performing a jamming attack, could prevent CH from receiving the hash chain values from one or more CNs which would result in a false exclusion of non-compromised CNs. If many CNs are affected, this could prevent CH from further generating reports, since there are less than t neighboring CNs left that are not excluded. The adversary could continue this attack in other areas of the WSN, disrupting the functionality of the whole network. Hence, we need to enhance the scheme to handle this type of attack. In the next section, we present solutions to this problem. IV. ADDRESSING THE JAMMING ATTACK Jamming attacks are a general problem in wireless networks. The shared wireless channel can be easily blocked by an adversary, resulting in a Denial of Service (DoS) of transmission or reception functionalities. Security protocols should not open the door for an adversary to cause damage (other than successful transmission or reception of messages) by performing a jamming attack. In [10], however, this is possible. It is assumed that a CN is compromised if it does not disclose the hash chain value used to generate an endorsement. As a result, this CN is excluded by CH. However, if CH does not receive the hash chain values because of a jamming attack, the CN is falsely classified as compromised and excluded from the report generation process. Next, we present different approaches that can be used to make the scheme presented in [10] resistant against a sophisticated jammer and we describe one solution in detail. A. Possible Solutions One way to cope with the jamming attack might be using jamming detection mechanisms. If there are indications of a jamming attempt, CH could not immediately exclude the CN from which it does not receive the hash chain value. However, detection of jamming alone is not sufficient, since even if we were able to detect that a jamming attack has been performed, we could not verify the previously received endorsement. Another approach would be a random variation in the disclosure schedule of the hash chain values. Thus, the adversary does not know the exact point in time he should perform the jamming attack. The problem with this approach is that we cannot extend the variation to an arbitrary long time span, since the verification of received endorsements should be as fast as possible to enable a quick reaction on false endorsements. Thus, the adversary just has to jam a short period of time to accomplish the goal that innocent CNs are falsely excluded. Alternatively, CH can perform a challenge-response like verification with the CN from which it does not receive the hash chain value. CH might request the hash chain value if it does not receive the value at the specified point in time. However, we still cannot distinguish whether CN does not respond or a jamming attack occurs. One approach that does not require any additional mechanisms such as jamming detection, introduces greylists and requires only slight modifications to the original scheme. Each CH maintains a greylist. CH adds a CN to the greylist if it does not receive the hash chain value from CN to verify the previously received endorsement at the specified point in time. CH does not use subsequent received endorsements from a CN that is listed in the greylist, until it receives a valid hash chain value to successfully verify the unverified endorsement. CH completely excludes a CN if a verification fails or if a specified threshold is reached, e.g., maximum time span without a successful verification or maximum entries in the greylist is reached. To enable a CN to be trusted again, it appends the last hash chain value which is allowed to be disclosed to the next endorsement sent to CH. This enables CH to verify the old unverified endorsement. If the verification of the old endorsement passes, CN is trusted again and the currently received endorsement can be used to generate the current report. If an adversary still performs a jamming attack, CH would not receive the message anyway and CN remains in the greylist. Generally, we cannot protect against jamming attacks that prevent reception of messages. However, applying this modification to the protocol prevents an adversary from performing a jamming attack that affects the scheme in such a way that an innocent CN is falsely excluded. We describe the enhanced scheme in the next section. 588

B. Enhanced Scheme In the enhanced scheme, the bootstrapping phase remains the same as in the original scheme. However, the report generation and verification phase are modified to cope with the jamming attack. Each CH maintains a greylist that stores the node identifiers of CNs from which CH does not receive hash chain values. Furthermore, a CN sends the last verification hash chain value that is allowed to be disclosed together with each endorsement it sends to CH. 1) Report Generation: We describe the modified report generation phase by means of two algorithms specifying the actions of CH and a CN. Algorithm 1 specifies the actions of CH. As in the original scheme, CH generates R and T M and broadcasts these values to all CNs in the cluster. Each CN i that agrees on R and T M generates an endorsement and sends it together with the last hash chain value End CNi c CNi Δ that is allowed to be disclosed to CH (see Algorithm 2). CH maintains a set F, containing all node identifiers of trusted CNs whose endorsements are accepted. Initially, after the bootstrapping phase, F contains the node identifiers of all CNs in the cluster. Furthermore, CH maintains a set G, containing all the node identifiers of greylisted CNs, i.e., those CNs from which CH did not receive a hash chain value to verify a previously sent endorsement. For each CN i from which CH receives the tuple (End CNi,c CNi Δ ), it first checks if this CN i is listed in its greylist G. If so, CH verifies the old endorsement for which it has not received a hash chain value at the specified point in time, using c CNi Δ according to Algorithm 4. The algorithm removes the node identifier of CN i from G and adds it back to the set of trusted nodes F if the verification passes. Otherwise, CN i is excluded from any further report generation. The detailed description of the verification is described in section IV-B.2. Next, CH temporarily stores each endorsement End CNi it receives from acnlistedinthesetf for future verification. After CH has received the endorsements, it calculates h(c CH R T M ) and selects t endorsements received from trusted CNs, and compresses them to one SEnd using bitwise XOR. The node identifiers of CH and the t CNs whose endorsements have been used to generate SEnd, are stored in a data structure V. The final message to the sink consists of R, T M,End, and V. Algorithm 2 describes the actions of a CN when it receives R and T M from CH to endorse (or not to endorse) a report. CN first checks that the measurement has been performed in the current interval. Next, it performs its own measurement R. If R matches R within a certain error range ε, CN generates an endorsement and sends it together with the last hash chain that is allowed to be disclosed to CH. To show the effect of a previously performed jamming attack, we continue the example shown in Figure 1. A report has been generated in interval I 1 and an adversary has value c CN Δ performed a successful jamming attack at time T 1 during the regular disclosure of the verification hash chain values. Thus, CH does not receive these values from some CN i and adds them to its greylist. If necessary, CH generates a new Algorithm 1 CHRepGen(t, c CH ) 1: Generate R and T M 2: Broadcast R, T M 3: while Receiving (End CNi,c CNi Δ )fromcn i do 4: if ID CNi G then 5: CHVerifyGreylist(c CNi Δ ) 6: end if 7: if ID CNi F then 8: store End CNi 9: end if 10: end while 11: End CH = h(c CH R T M ) 12: End = End CH 13: V = {ID CH } 14: select t endorsements End g1,...,end gt 15: for i =1to t do 16: End := End End gi 17: add node identifier g i to V 18: end for 19: Sendto(Sink):R, T M,End,V Algorithm 2 CNRepEnd(c CN, I, R, T M, ε) 1: if T M I then 2: Generate R 3: if R ε R R + ε then 4: End = h(c CN R T M ) 5: Sendto(CH):End,c CN Δ 6: end if 7: end if report for the sink, but without these CN i. Assume that a new report is generated in interval I 4. When a CN i sends an endorsement to CH, it includes the last hash chain value that is allowed to be disclosed within this message; in this case c CNi 2. Using this value, CH can calculate c CNi 1 and verify the previously received endorsement. The detailed verification process is explained in section IV-B.2. At this stage we assume that a jamming attack has, indeed, occurred and thus, the verification of the old endorsement passes. CH adds CN i back to F and accepts the currently received endorsement. 2) Verification: The sink verification remains the same as in the original scheme. However, to address the jamming attack, the verifications of CH have to be modified. We distinguish between two cases, (1) when CH directly verifies the endorsements of the CNs when they disclose their hash chain values at time T, and (2) the greylisting-based verification when CH did not receive the value at T. Algorithm 3 specifies the actions of CH in the first case. Before execution of the algorithm, CH removes all CNs from which it does not receive a verification hash chain value from the set F and adds them to the greylist G. For the remaining CNs Algorithm 3 is executed. First, validity of the disclosed hash chain values is verified. If the verification fails, CN is removed from F, i.e., excluded from any further report 589

generation. A reaction is performed if the endorsement of the CN has been used to generate SEnd, i.e., either CH initiates a new report generation or CH waits for a new query from the sink. In the case the verification passes, CH calculates the endorsement of CN and compares it with the temporarily stored endorsement received in the report generation phase. Again, if this verification fails, CN is removed from F, and if the endorsement has been used to generate SEnd, a reaction is performed. Algorithm 3 CHVerify(R,T M,V,ID CN,End CN,c CN,cCN 1,F ) 1: if h(c CN ) ccn 1 then 2: F = F \{ID CN } 3: if ID CN V then 4: reaction 5: end if 6: else 7: 8: End CN = h(c CN R T M ) if End CN End CN then 9: F = F \{ID CN } 10: if ID CN V then 11: reaction 12: end if 13: end if 14: end if In the case that CH does not receive the hash chain value from a CN to verify a previously sent endorsement, CH executes Algorithm 4 in the next report generation phase when CN sends a new endorsement together with the last hash chain value that is allowed to be disclosed. First, CH removes CN from G. Next, CH verifies that the received hash chain value is correct. If it is correct, CH recomputes the endorsement and compares it with the stored old endorsement. If both verifications pass, CH re-inserts the node identifier of CN into its set of trusted nodes F and accepts endorsements from this node again. Otherwise, this CN is excluded, i.e., endorsements from this node are not accepted and CH can delete the pairwise key and the verification value of this CN. Algorithm 4 CHVerifyGreylist(R old,tm old,v,id CN, End old c CN Δ,cCN Δ 1,F,G) 1: G = G \{ID CN } 2: if h(c CN Δ )=ccn Δ 1 then 3: calculate c CN old used to generate Endold CN 4: End old CN = h(c CN old Rold TM old) 5: if End old CN = End old CN then 6: F = F {ID CN } 7: end if 8: end if CN, We continue the examples from above. An adversary has successfully performed a jamming attack at time T 1, i.e., CH did not receive hash chain values of some CN i and thus, cannot verify the endorsements it has received in interval I 1. Thus, CH has added these CN i to its greylist G and has generated a new message for the sink without the nodes in the greylist. In the next report generation in interval I 4 (when there is no jamming attack), CH receives c CNi 2 enabling CH to calculate c CNi 1 and to verify the received endorsements. In this example, the verifications pass since a jamming attack has, indeed, prevented CH from receiving the verification hash chain values. Thus, the jamming attack has no affect in the modified protocol, i.e., an adversary cannot blame innocent CNs so that they are excluded by CH. V. ANALYSIS In this section, we first summarize the security analysis of the original scheme. Then, we analyze the impact of the modifications to address the jamming attack in the enhanced scheme. In the second part of the analysis, we evaluate the performance of the enhanced scheme and compare it with the original scheme. A. Security Analysis The goal of the original scheme is to defend against false data injection and FEDoS attacks. It should be used in combination with, e.g., the STEF scheme, to defend also against PDoS attacks. [10] shows that an outside adversary or an adversary who has compromised less than t +1 nodes, cannot inject false data to successfully deceive the sink. An adversary compromising t+1 or more sensor nodes is able to. However, the impact of these node compromises is mitigated by the STEF scheme. It prevents an adversary from performing PDoS attacks and limits the node compromise to the region of the compromise, i.e., an adversary cannot inject false reports appearing from arbitrary locations. It is also shown that an outside adversary cannot perform a FEDoS attack. An adversary who has compromised one or more CNs is able to perform a FEDoS attack. However, the (potentially) compromised CN is detected at the time when the hash chain values are disclosed. If either the verification fails, or the CN does not send the verification hash chain value, CH excludes the CN from any further report generation. Because of the latter case, innocent CNs can be falsely excluded if an adversary performs a jamming attack at the time of disclosure of the hash chain values. The enhanced scheme proposed in this paper, addresses this issue. The original scheme is modified and a greylist is introduced. CH adds a CN to this list if it does not receive the hash chain value to verify the previously received endorsement. The next endorsement message, CH receives from CN, includes a hash chain value that enables CH to verify the old endorsement. If the verification of the old endorsement passes, the currently received endorsement can be used to generate the current report. It is sufficient to send the verification hash chain values together with the endorsements, since the information that an old endorsement was correct or not is only required if we receive a new endorsement to decide whether this endorsement can be used for the current report generation. At an earlier point in time, the adversary could 590

still perform the jamming attack. If the verification of the old endorsement fails, CN is excluded from any further report generation, since it has indeed performed a FEDoS attack. Thus, as in the original scheme, an adversary can only send false endorsements until the point in time where verification hash chain values have to be disclosed. In addition, a jamming attack with the goal that CH falsely excludes innocent CNs is not possible anymore. However, constant jamming attacks with the goal of disrupting the communication can prevent a successful report generation since either CH does not receive t endorsements or the message for the sink is blocked by the jammer. But, as soon as the jammer leaves the region, new reports can be generated and old endorsements can be verified. To address the general issue of jamming attacks, other techniques (e.g., [13], [14]) can be used. B. Performance Analysis In this section we analyze the performance of our scheme in terms of storage requirements and energy consumption. 1) Storage Requirements: The only additional storage space required in the enhanced scheme compared to the original scheme [10] is required for the greylist. Thus, to quantify the storage requirements SR let SR G, SR H, SR V, L ID, L R, L T, and L H respectively denote the storage requirements for the greylist (i.e., IDs and required endorsements), the storage requirements for the hash chain, thestorage requirements for the verification hash chain value(s) for one node, thelength of an ID, thelength of a report, thelength needed for the time of measurement, and the length of an endorsement (i.e., the length of a hash value). Let u +1 be the number of nodes in the cluster, v the average number of endorsement sets CH stores, i.e., the number of reports for which endorsements are temporarily stored, and w the number of endorsements for one specific report. Thus, the storage requirements for CH are: SR = SR G + SR H + u (SR V + L ID )+ v (L R + L T + w (L H + L ID )) Example 1: Suppose a lifetime of 10 years where hash chain values are valid for one second. Using an efficient hash chain construction proposed in [17] requires 1188 Bytes (9504 Bits). Let the length of a report be 24 Bytes, the length of T M be 29 Bits, the length of an endorsement be 64 Bits, the length of an ID be 10 Bits, SR V be 144 Bit, u =6, v =2, and w =5. The storage space for the greylist is zero if no node is greylisted. The worst case for this example is that the remaining node is greylisted and its ID and last endorsement are stored, i.e., SR G = 74 Bits. Thus, the storage requirements are SR = 11684Bits = 1460.5Bytes. As in the original scheme, the main storage is required by the hash chain where the majority can be stored in the 512 KBytes flash memory of a Mica2 mote. Currently needed values occupy only a small fraction of the 4 KBytes RAM. 2) Energy Consumption: In [10], the energy consumption of the original scheme is evaluated. Furthermore, the energy consumption if used in combination with the STEF scheme is compared to the PVFS scheme [5]. The energy consumption of the sensor nodes can be divided into two parts, (1) the energy required for the cluster for report generation and endorsement verification, and (2) the energy to forward the message along multiple hops to the sink. The enhanced scheme differs only slightly in the local communication overhead for the cluster. The energy for sending and receiving the endorsement message is slightly higher since a verification hash chain value is included in the message. Compared to a typical example presented in [10], the energy consumption for a report generation increases about 11.8% from 11.66mJ to 13.04mJ. VI. CONCLUSIONS In this paper, we examine the scheme against FEDoS attacks presented in [10] and identify a possible attack. A jamming attack could result in a falsely exclusion of non-compromised sensor nodes. To address this issue, we discuss possible solutions and present an enhanced scheme. Therefore, we modify the original scheme and introduce a greylist. Furthermore, we show that the additional overhead of the enhanced scheme is only marginal compared to the original scheme. REFERENCES [1] I. Akyildiz, W. Su, Y. Sankarasubramaniam, and E. Cayirci, A survey on sensor networks, IEEE Commun. Mag. 40, vol. 8, 2002. [2] J. Deng, R. Han, and S. Mishra, Defending against path-based DoS attacks in wireless sensor networks, in SASN 05: Proceedings of the 3rd ACM Workshop on Security of Ad Hoc and Sensor Networks, 2005. [3] F. Ye, H. Luo, S. Lu, and L. Zhang, Statistical en-route filtering of injected false data in sensor networks, in Proc. IEEE INFOCOM, 2004. [4] S. Zhu, S. Setia, S. Jajodia, and P. Ning, An interleaved hop-by hop authentication scheme for filtering false data in sensor networks, in IEEE Symposium on Security and Privacy, 2004. [5] F. Li and J. Wu, A probabilistic voting-based filtering scheme in wireless sensor networks, in IWCMC 06: Proceeding of the international conference on communications and mobile computing, 2006. [6] H. Yang, F. Ye, Y. Yuan, S. Lu, and W. Arbaugh, Toward resilient security in wireless sensor networks, in MobiHoc 05, 2005. [7] L. Zhou and C. Ravishankar, A fault localized scheme for false report filtering in sensor networks, in ICPS 05: IEEE International Conference on Pervasive Services, 2005. [8] H. Yang and S. Lu, Commutative cipher based en-route filtering in wireless sensor networks, in IEEE VTC Wireless Security Symp., 2004. [9] C. Krauß, M. Schneider, K. Bayarou, and C. Eckert, STEF: A secure ticket-based en-route filtering scheme for wireless sensor networks, in 2nd Int. Conf. on Availability, Reliability and Security (ARES), 2007. [10] C. Krauß, M. Schneider, and C. Eckert, Defending against falseendorsement-based DoS attacks in wireless sensor networks, in WiSec: Proc. of the First ACM Conference on Wireless Network Security, 2008. [11] Y. Zhang, W. Liu, W. Lou, and Y. Fang, Location-based compromisetolerant security mechanisms for wireless sensor networks, IEEE Journal on Selected Areas in Communications, vol. 24, Issue 2, 2006. [12] W. Zhang and G. Cao, Group rekeying for filtering false data in sensor networks: A predistribution and local collaboration-based approach, in IEEE INFOCOM, 2005. [13] W. Xu, K. Ma, W. Trappe, and Y. Zhang, Jamming sensor networks: Attack and defense strategies, IEEE Network, vol. 20, no. 3, 2006. [14] W. Xu, W. Trappe, and Y. Zhang, Anti-jamming timing channels for wireless networks, in WiSec: Proc. of the first ACM conference on Wireless network security, 2008. [15] MICA2: Wireless measurement system, http://www.xbow.com/. [16] A. Perrig, R. Szewczyk, J. D. Tygar, V. Wen, and D. E. Culler, SPINS: Security protocols for sensor networks, Wirel. Netw., vol. 8, no. 5, 2002. [17] Y.-C. Hu, M. Jakobsson, and A. Perrig, Efficient constructions for one-way hash chains, in Applied Cryptography and Network Security (ACNS), 2005. 591