Guard Duty Alarming Technique (GDAT)
A synopsis of:
Rababaah, H., and Shirkhodaie, A. 2007. Guard Duty Alarming Technique (GDAT): A Novel Scheduling Approach for Target-tracking in Large-scale Distributed Sensor Networks. IEEE International Conference on Systemd of Systems Engineering, 2007. SoSE’07. Volume , Issue , 16-18 April 2007 Page(s):1 – 6.
Many wireless sensor network target tracking approaches assume that an intruder will enter the detection region from the perimeter. These techniques conserve energy by allowing interior nodes to sleep until an intrusion occurs, thus increasing the longevity of the network. However, this strategy leaves the interior of the network vulnerable to attacks that bypass the perimeter, such as aerial or insider attacks. Rababaah and Shirkhodaie propose a clustering and tracking technique that provides the efficiency of image processing techniques while maintaining sensing throughout the detection region. This method, called Guard Duty Alarming Technique (GDAT), is inspired by military practice of rotating guard duty. While most soldiers sleep, one soldier is ordered to remain on guard duty for an assigned period. In GDAT, one sensing node is “on guard” actively sensing while its other cluster members sleep.
GDAT requires two types of nodes: head nodes and sensing nodes. Head nodes are provisioned with both strong radios to communicate with the base station and with global positioning receivers to append location information to intrusion alerts. Sensing nodes are equipped with intrusion detection devices and only require sufficient power to communicate with the head nodes.
Following network deployment, both head nodes and sensing nodes are awake. Head nodes broadcast advertisements requesting that sensing nodes adopt them as their cluster head. Sensing nodes accept the first offer they receive, record the ID of the head node, and send an acceptance message to the head node. Each head node can accept 32 sensing nodes into its cluster.
The tracking phase begins once clustering is complete. The cluster head assigns one sensing node to “guard duty” for a small interval and instructs the other sensing nodes to sleep. The sensing node can reside anywhere within the cluster. When the sensing node detects an intrusion, it alerts the head node, which appends GPS coordinates to the alert and forwards it to the base station. Following the intrusion, the sensing node will remain on duty until its shift is complete. At that point, the head node will assign another sensing node to guard duty.
Important assumptions effect the success of GDAT. Most significantly, GDAT assumes that head nodes and sensors will be normally distributed across a detection region following a probability distribution function. Factors such as rugged terrain, battle, or natural forces can adversely influence the distribution of head nodes and sensing nodes. In comparison to image processing techniques, GDAT leaves the perimeter porous. Even though it delivers higher accuracy throughout the network, it may not detect an intruder crossing the perimeter as quickly as an image processing technique. The authors indicate that they will include image processing techniques in future GDAT research.
December 15, 2007
Posted in: Computing 
No Comments
MiniSec: A Secure Sensor Network Communication Architecture
A Review of:
Luk, M., Mezzour, G., Perrig, A., and Gligor, V. 2007. MiniSec: a secure sensor network communication architecture. In Proceedings of the 6th international Conference on information Processing in Sensor Networks (Cambridge, Massachusetts, USA, April 25 – 27, 2007). IPSN ’07. ACM, New York, NY, 479-488.
DOI= http://doi.acm.org/10.1145/1236360.1236421.
The research team that introduced SPINs and microTesla propose a wireless sensor network security architecture called MiniSec that provides improved efficiency in delivering confidentiality and integrity to wireless sensor networks. MiniSec secures both unicast and broadcast communication. MiniSec’s most significant contribution rests in its use of the same block cipher to provide confidentiality and authentication. MiniSec also introduces a novel semantic security strategy that only requires transmission of a fragment of the initialization vector (IV). Third, MiniSec utilizes increasingly available mote memory to defend against replay attacks.
When evaluating their security claims, the authors assume that the radio channel is insecure. An attacker, with potentially unlimited computational and energy resources, can intercept, modify, and replay any radio communications.
MiniSec clearly advances the WSN security space. TinySec minimized memory and energy use by omitting replay protection and using a single network shared key. ZigBee maintains a high level of security by sending an 8-byte IV. The authors claim that MiniSec consumes 1/3 the memory of TinySec.
MiniSec employs a block cipher mode known as Offset Code Book (OCB) [1]. OCB provides authentication and encryption in one pass. OCB takes in the message, the key, and a nonrepeating nonce, and concurrently generates the ciphertext and a tag used for authentication. The nonce provides semantic security, assuring that any two identical plaintext messages encrypted with the same key yield different ciphertext. The tag functions as a message authentication code (MAC). An advantage of OCB is that it does not cause ciphertext expansion; it produces ciphertext the same length as the plaintext. TinySec and ZigBee require two block cipher passes; one for confidentiality and another for authentication.
Bloom filters and loose time synchronization help defend against replay attacks. Bloom filters allow nodes to efficiently store a fingerprint of received messages into an array and quickly query the array to determine if the message has already been seen. Bloom filters guarantee that replayed messages will be detected. However, there is a possibility that new messages may be identified as replayed messages.
The underlying block cipher used in the MiniSec implementation is Skipjack, with a block size of 64 bits. OCB requires the nonce to be the same length as the block size, so the counter is also 64 bits. This monotonically increasing counter guarantees semantic security. The tag, used for authentication, is recommended to be to 32 bits. Symmetric keys are set to 80-bits. MiniSec uses a counter resynchronization protocol similar to the one used in SNEP.
MiniSec is composed of two schemes, MiniSec-U for unicast messaging, and MiniSec-B for broadcast messaging. The two schemes differ in the way they handle counters for replay protection. Minisec-U requires each receiver to maintain a counter for each sender. MiniSec-B uses Bloom filters. Shared counters were also used in SNEP, part of the SPINS suite.
MiniSec-U reduces the cost of transmitting counters. It conserves radio energy by only sending the last few bits (the LB value) of the 64-bit counter. The LB value is selected based on the potential for dropped packets. A low LB value can be used in environments with less potential for interference, thus reducing the communication overhead. The protocol requires two keys two counters for each pair of communicating nodes, one per direction.
Counters can not be used in broadcast communication because of the complexity of keeping the counters synchronized among multiple nodes. OCB provides confidentiality and authentication for broadcast communication, but a novel approach is required to defend against replay attacks. One proposal is to use a sliding window. Time is split into a series of finite epochs. The length of the epoch is selected based on the estimated network latency. Each epoch is assigned a unique ID, which is used as the nonce. When an encrypted message is received, it is deciphered with both the current epoch ID and the previous epoch ID. If neither ID yields successful decryption, the packet is considered a replay. With this approach, a packet sent early in an epoch can be replayed throughout the epoch.
Bloom filters detect replayed messages within an epoch. Each receiving node mainains two Bloom filters; one for the current epoch and one for the previous epoch. When a packet is received, the receiver first validates the packet by performing OCB decryption. If this succeeds, a test is performed to determine if the packet was replayed. The receiver first queries the Bloom filter for the packet. If it is found, the packet is considered a replay. If it is not found, it is considered new and added to the Bloom filter. This strategy will detect all replay attacks within the epoch.
MiniSec provides a high level of security with less overhead than its predecessors. Implementation details such as packet length, key length, and the authentication tag influence the level of security. While TinyOS uses only a 2-byte CRC, MiniSec uses a 4-byte tag. The authors recommend using a 32-bit tag because it was referenced in a paper on banking application security. Use of cryptographic keys replaces the functionality of the TinyOS group ID, thus this field is dropped. Like TinySec, MiniSec adds a 2-byte source address. Overall, MiniSec adds three bytes to the standard TinyOS packet.
MiniSec achieves notable efficiency while maintaining a high level of security. It reduces the transmission overhead of TinySec by two bytes. MiniSec reduces computational overhead by employing OCB. This allows for processing the ciphertext and authentication tag in one pass.
[1] Rogaway, P., Bellare, M., Black, J., and Krovetz, T. 2001. OCB: a block-cipher mode of operation for efficient authenticated encryption. In Proceedings of the 8th ACM Conference on Computer and Communications Security (Philadelphia, PA, USA, November 05 – 08, 2001). P. Samarati, Ed. CCS ’01. ACM, New York, NY, 196-205. DOI= http://doi.acm.org/10.1145/501983.502011.
December 4, 2007
Posted in: Computing No Comments
AMSecure
A synopsis of:
Wood, A. D. and Stankovic, J. A. 2006. AMSecure: secure link-layer communication in TinyOS for IEEE 802.15.4-based wireless sensor networks. In Proceedings of the 4th international Conference on Embedded Networked Sensor Systems (Boulder, Colorado, USA, October 31 – November 03, 2006). SenSys ’06. ACM, New York, NY, 395-396.
DOI= http://doi.acm.org/10.1145/1182807.1182873
In this report, Wood and Stankovic describe implementation of hardware accelerated cryptography in TinyOS. The hardware module is wired between the Active Message (AM) module and the radio. This strategy appropriates bytes from the message payload to identify the type of cryptography employed.
The four cryptographic modes specificed in IEEE 802.15.4 are offered: no cryptography, authentication-only with CBC-MAC, encryption-only with CTR mode, and authenticated encryption with CCM (CTR with CBC-MAC ). The system consumes between one and nine bytes of the 29-byte TinyOS payload, depending on the cryptography utilized. All cryptographic operations are based on AES. In order to preserve backward-compatibility with legacy TinyOS messaging, a compile-time flag is set to distinguish standard TinyOS Active Messages from AMSecure messages.
The strategy was evaluated based on processing and communication overhead. By using a hardware cryptographic module, AMSecure message processing time is kept to a low, predictable level. The message overhead resulting from addition of MAC decreases as payload length increases. With a standard 29-byte payload, addition of authentication and encryption result in 20 percent message overhead. This drops to approximately 8 percent with a 100 byte payload. Processing overhead predictably increases with message payload. When receiving an AMSecure message, the AMSecure module must strip the header and MAC, perform cryptographic operations, and signal the payload to the higher layers. For a 90-byte payload, the receive processing time increases from about 500 microseconds for a standard TinyOS message to 1750 microseconds for an authenticated, encrypted AMSecure message. When transmitting a message, the AMSecure module must shift the original payload to make room for AMSecure headers. This increases processing time by a similarly predictable amount.
As this report was only a poster abstract, more implemetation details remain to be published. However, the authors have proven that AES can play a role in wireless sensor networks.
November 12, 2007
Posted in: Computing No Comments