Denial of Sleep attacks in Wireless Sensor Networks
The radio transceiver of a mote is acting like a beacon and wakes up every t time interval to check for radio activity. This is a common strategy to save energy consumption in small devices like the MICAz or the SPEC mote, where battery supply is limited. A Denial of Sleep attack will cause the transceiver to remain awake for long intervals where it was not supposed to. The radio transceiver is one of the components which cause a lot of energy consumption on a mote and a sophisticated attack will drain as much energy as to bring down the wireless network.
Such strategies attack on the link layer protocols (MAC), therefore I will focus on the MAC protocols designed for WSN.
For the implementation of the model application and the DoS nodes, I will be using the MICAz motes, the nesC programming language and TinyOS-2.x with the stable version of the cc2420_lpl radio stack. This is the most up-to-date (2007) radio stack provided in TinyOS-2.x for the cc2420 chip.
The MAC protocol
TinyOs-1.x is using the B-MAC protocol, but Low Power Listening (beaconing) functionality is not implemented for the MICAz platform. This is because the MICAz mote has the cc2420 chip which supports the IEEE/802.15.4 standard. In this standard long preambles described in the B-MAC protocol are not possible and the cc2420 chip does not allow to extend the preamble. The cc2420 chip does support CSMA/CA though, using CCA (Clear Channel Assessment). [David Moss]
In TinyOS-2.x the cc2420_lpl is a MAC protocol, similar to the B-MAC protocol, which supports Low Power Listening. To get around the problem with long preambles, the long preamble is now replaced with repeated short frames that precede the frame with the actual payload. A receiver will check for valid traffic every t time interval, therefore the sender needs to send a long enough train of short messages that will ensure that the receiver will listen to the traffic in a asynchronous manner. In order to achieve reliability, the protocol is sending short messages for 2t time interval, that is double the time of the duty cycle of the receiver. Once the receiver determines that there is valid traffic it can send an ACK and the sender will quit sending short messages. [David Moss]
Also, the new cc2420_lpl radio stack supports some guard against Denial of Sleep attacks. The algorithm samples the incoming traffic to check for valid frames or if the destination address is valid [David Moss]. Ofcourse this simple approach, will only guard against simple attacks that don't use any information about the traffic in the network. More sophisticated attacks would sniff data in order to gain information about the frames and produce legitimate packets with valid destinations. I will actually try and implement such an attack as a proof of concept code, then I ll try and look for countermeasures.
Attack strategy 1 (jamming the radio)
This attacker mote is simply jamming the radio and is affecting the sender. The attacker is ignoring the rules of CSMA/CA and is transmitting aggressively. Thus, the sender is blocked from transmitting any frames. A jamming attack is not exactly a Denial of Sleep attack, but is the first step for me before I start an attack that uses frame collisions.
In order to ignore the rules of Collision Avoidance, I have disabled CCA by replacing the CC2420Transmit.sendCCA() function with the CC2420Transmit.send() function. The CC2420Transmit interface is provided by CC2420TransmitC and it is used in CC2420CsmaP. I have also changed the timer to fire up every 1 millisecond to make it difficult or say impossible for a sender to pass through the jam. If CCA was enabled some messages actually can be transmitted even if the attacker is sending in messages every 1 millisecond. When CCA is disabled on the attacker it is logical to assume that some messages collide and that the sender is actually trying to re-transmit. Most of the time though, the sender is possibly backing off and never transmits a message and that's why this is not a real Denial of Sleep attack, since it is not forcing the transceiver to be in an awake state.
This simple approach of attack could have happened accidentally by some device which interferes unintentionally and doesn't use any CSMA/CA mechanisms. Thus it is very dangerous that the channel would be jammed and no messages can pass through to the BaseStation.
observation is that an attacker could also spoof the node_id once
jammed the radio and send maliciously the wrong data to the
jamming attack is causing some frame collisions but I am going to
further study what's happening with the protocol and make this attack
a little bit more sophisticated. For example instead of simply send
frames every 1 millisecond, the attacker will be smart enough to send
only just after the sender has transmitted, thus creating frame
collisions. Then the sender will never get an ACK back and will keep
re-transmitting the same frame. Even if the sender will be backing
off, the radio could still remain on and wasting energy.
The sender is sending 10 packets every 3 seconds, add 1.5 second per packet for processing total activity is approximately 45 seconds. Under normal circumstances (with ACKS) the radio activity in those 45 seconds is 5 seconds only (statistically). Under the attack the sender will have its radio active for total of 20 seconds, when duty cycle at the receiver is 1 second. That is in 45 seconds we have 25 seconds of idling and 20 seconds of radio activity. There is a significant difference of the radio activity, but the Attacker will run out of battery sooner because during those 45 seconds it has almost 100% radio activity for jamming the radio.
Instead of sending 10 packets and stop, I should start a timer and wait for 45 seconds and count the radio and idle time, then stop. It shouldn't matter how many packets I have sent during that period. It doesn't matter for this attacker, but maybe for the next attacker it does.
Attack strategy 2 (frame collisions)
The approach to frame collisions is to put the attacker into Listening mode and once it senses traffic on the channel turn immediately onto Transmission mode and send a frame, ignoring any CCA mechanisms. This kind of attack is actually forcing the sender transceiver to remain awake for longer periods re-transmitting frames.
Typically in a Wireless Sensor Network a sender will only send some information whenever some event happens. This event could happen rarely or not so often. If this is the case then the frame collisions attack may not be as effective. Yet again, if the Sender wants to send a critical message which requires 100% reliability then it will keep re-trying for longer periods to send the same message, until it receives an acknowledgement from the receiver. In that case a Denial of Sleep attack which causes frame collisions on the ACKS, would be very effective.
A simpler approach is to synchronise the attacker with the receiver's duty cycle and once the receiver is checking for valid packets, start transmitting frames, thus causing the receiver to never send an ACK back. In order to synchronise, the attacker must approximate the duty cycle of the receiver. In order to do that the attacker must send a valid frame to the receiver, receive the ACK, immediately after that send a second frame and receive the second ACK. The difference between the second ACK and the first ACK, plus some latency minus some time of CCA work, is the approximation of the duty cycle of the receiver. Simpler than that is to read the duty cycle time in ms from the meta data in the frame, provided there is any. Synchronisation is trivial, once received an ACK you know that the receiver has just started duty cycling. There is a problem with this approach. There may be more than one receivers, thus making synchronisation difficult, n attackers would be needed for n receivers, or the attacker would cause special traffic so the receivers are awake at different periods of time, problem is the attacker would run out of battery sooner than the receivers. Notice that while the attacker is interfering with the receiver, the sender senses traffic in the channel and will usually back off, thus if there is too much interference, the sender will always back off, which keeps it from transmitting anything.
Another one is to synchronise with the sender. When a sender sends repeatedly a packet, it pauses between the frames to check for the ACK. If the attacker can synchronise to cause traffic at each check point of an ACK, then the sender will never be able to receive the ACK, due to frame collisions. This method can be same with the receiver synchronisation.
Attack strategy 3 (synchronise ALL the receivers)
This strategy is novel and is described in the dissertation
Nodes will agree on a sequence of different channels. Check TSMP whitepaper from Dust Networks to see how they did this to optimise against interference. When a channel is compromised by an attacker or there is too much interference, then change to another frequency. Changing frequency is also used in the military in order to hide data. Data are transmitted in many different frequencies and it is difficult for someone to observe all the frequencies. This technique requires nodes to agree on which frequencies they will be using and when they will be using them. This could require time synchronisation if frequencies are changed in time frames.
If time synchronisation is required a simple approach would be to use a broadcaster node that would broadcast the time across the whole network and all the nodes would synchronise on that. This is not a very practical solution since some nodes could be outside the range of the broadcaster or transmission latencies could cause inaccurate synchronisation. Another approach would be that the nodes exchange the time value with each other and the median value is agreed to be the synchronised time.
So why not just frequency hopping?
One of the challenges of frequency hopping systems is to synchronize the transmitter and receiver. Synchronised protocols are not always the choice in Wireless Sensor Networks and may require extra energy consumption. Also the synchronisation solutions could fail.
The GMAC protocol (clustering and encryption).
Nodes will not accept traffic from just anyone, thus an attacker becomes an outsider and all maliciously transmitted frames will be ignored. This is achieved by dividing the network into clusters, and cluster nodes will only communicate with a gateway node. A gateway is voted periodically to avoid overhead on a single node. To avoid spoofing and sniffing the headers of the frames are also encrypted.
Encryption is usually lightweight on WSN (one could still break in)
and also requires extra energy consumption.
I will be measuring the radio activity in microseconds: 1 second = 1 000 000 microseconds (1MHz). In order to do that I must make sure that the clock provided in TinyOS can give me the granularity that I am looking for.
The MICAz processor runs at 7.37MHz. The CounterMicro32C module provides a counter which runs at
CPU frequency / 8. This is approximately 1 tick per 1 microsecond, but not exactly. It's actually:
7 370 000 / 8 = 921 250 ticks per second (921.25 KHz ~ 1MHz)
The error percentage is: 8 / 7 370 000 = 1.0854816825-e6%. Therefore, to be accurate I need to multiply my results with:
T = 1 000 000 / 921 250 = 1.0854816825
In order to measure the radio activity on the sender side, I will get the counter value t1 just before the send() command and the counter value t2 just after the sendDone() event. The difference of the two will tell me approximately for how long the radio was on (some instructions before and after the events may cause a small delay). Therefore my formula would be: Diff = (t2-d) – (t1+d), for small values of d. The overall radio activity would be the sum of all the diff for each packet that has been sent:
Sender Radio Activity = Sum (Diff1,Diff2,...,DiffN);
From the first experiments it looks like this: With LPL and NO ACKS: Diff = 1.8 milliseconds. With LPL and ACKS: Diff = 0.8 millisecond.
No drivers found for the MTS300/310 sensorboard. Maybe check in the repository. Nevertheless, sensor values are not important. I could also use the generic DemoSensorC interface and implement a mock sensor.