Security Protocols For Sensor Networks Spins Computer Science Essay

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

Several security protocols have been implemented to make sensor networks more trustworthy and reliable in order to satisfy the security requirements against different types of attacks. Common security protocols are SPINS (Perrig 2001), LEAP (Zhu 2003), LSec and TinySec which is implemented in TinyOS. This section will analyse these different security protocols.

Security protocols for sensor networks (SPINS)

SPINS consist of two security building blocks: SNEP (Secure Network Encryption Protocol) and microTESLA (micro version of Times, Efficient, Streaming, Loss-tolerant Authentication Protocol). SNEP provides data confidentiality, two-party data authentication and data freshness and microTESLA provides authenticated broadcast for severely resource-constrained environments (Perrig 2001). These two protocols specifically address self-organizing wireless sensor networks that have multi-hop routing topology. SPINS aim to provide secure communication for single node to base station, base station to a single node and base station broadcast to all nodes. It also minimizes utilization of energy, storage and bandwidth resources. However, SPINS does not cater for node-originated broadcast messages.

SNEP is a base station centric security model. Each node shares a secret key with the base station. These keys are set up through the base station. It has low communication overhead as it appends only 8 bytes MAC per message. The MAC is generated by running the plaintext message and the counter through the RC5 block cipher in CBC-MAC mode. The CRC field is dropped since the MAC provides message integrity (Perrig 2001).

SNEP also maintain a counter at endpoints to prevent replay attacks. To reduce transmission rate, the counter is not incorporated with the message. The counter must be stored in the sensor node for each communication. Semantic security prevents eavesdroppers from inferring the message content from the encrypted message. A message authentication code (MAC) is used to achieve two-party authentication and data integrity. If the MAC value is correct, a receiver can be sure that the message is from the legitimate sender. However, sensor network protocols commonly avoid using counters because they increase communication overhead.

The counter helps in the encryption process and in calculation of MAC. Thus, achieving semantic security which means that encrypting the same message would output unique ciphertext each time.


Secure broadcasting in a wireless sensor network remains a difficult problem. uTESLA provides authenticated broadcast by providing security based on symmetric key approach. Symmetric key cryptography makes use of a shared key. If the shared key is disclosed, an adversary could use it to spoof messages from legitimate sender. uTesla solved this problem by periodically rotating the chain of symmetric keys. This method is ideal when broadcast messages are sent by a base station (Perrig 2001).

To authenticate broadcast messages, a random key, Kn is selected by the base station. A one way-hash function F is applied to the random key generating keys Kn-1, Kn-2, Kn-3… K0. Keys are rotated on a specific time interval. When the base station broadcasts a message, a MAC is attached to the message that was generated with key Ki. Nodes receiving the message can authenticate it by verifying the MAC with key Ki obtained by F (Ki+1). New recipients cannot authenticate the message and must buffer it until the next key Ki+1 is disclosed. Ki will be calculated by doing a one-way hash function to Ki+1. Time synchronization between the nodes and base station is necessary to obtain the key else the validation of the MAC will fail.

Both SNEP and uTesla uses RC5 cipher. CBC-MAC is used for message authentication and generation of random numbers. Code memory is preserved since both encryption and decryption is provided by the same function which is RC5 in counter (CTR) mode. Other advantages of RCS include its efficiency, duplicates avoidance, and small lookup tables.

Limitations of SPINS

The SPINS model has security concerns such as the security of compromised nodes, DoS issues and network traffic analysis issues. This protocol is not applicable for ad hoc and mobile sensor applications (Zia 2006).

Localized encryption and authentication protocol (LEAP)

Designed to support in-network processing, LEAP (Zhu 2003) is a key management protocol for WSNs, at the same time restricting the security impact of a compromised node. Authors of LEAP claim that the dissimilar messages types exchanged between sensor nodes have different security requirements. The single keying mechanism is not sufficient for meeting these security requirements. Therefore, LEAP makes used of four keys which are individual key, pair-wise key, cluster key, and group key. Each node in the network is preloaded with an individual key from which the other keys can be generated.

Individual Key

Every node shares a unique key with the base station. This key is used to secure communication between a node and a base station. In order to save the base station's memory, each individual key is generated whenever a message is received. Each individual key is generated using a master key, K­m, and the node's unique ID. For example, the key Kbn shared between base station (B) and a node (N) would be Kbn = fKm(N). Message authentication codes (MACs) is generated over the packet from this key. Base station or individual nodes can authenticate the packet by verifying the MAC with the shared key of the node.

Group Key

A group key, KG is pre-loaded into every node before it is deployed. This key is shared by a whole group. When base station needs to broadcast messages to a particular group, a group key is used to encrypt these messages. Base station makes use of broadcast messages to issue new tasks, query nodes and send interests messages. However, if the group key found on a node is compromised, an efficient rekeying mechanism is necessary for updating this key.

Cluster Key

A cluster key is a key shared by a node and all its neighbors and is used to secure local broadcast message. A node generates a random key and encrypts the random key using pair-wise key. This computed key is shared among its neighbors. Cluster key is used to perform secure in-network processing. Data are encrypted using this key to perform secure aggregation and dissemination within the cluster. Each node possesses a unique cluster key that it uses to authenticate its message. Moreover, compromising a node allows an attacker to disrupt only part of the network.

Pair-wise Key

Every node shares a pair-wise key with each of its direct neighbors. Pair-wise keys are used to authenticate the source node. To set up a pair-wise key, a node generates a master key using the pre-loaded key, Ki and broadcast a HELLO message containing its unique ID. Neighbor nodes will respond with an ACK message including their IDs and message authentication code (MAC). The pair-wise shared key is then calculated.

It can be used to securely transfer cluster keys to its neighbors.

Advantages of LEAP

LEAP can minimize the effect of selective forwarding attack as it uses group broadcast. Nodes which are 2 hops away will not be affected by this attack. LEAP can prevent HELLO Flood attack as nodes accept packets only from its authenticated neighbor. Sybil attack can also be prevented by providing unique ID authentication for each node. After key establishment between neighbor nodes, it is difficult for an adversary to convince a node to change geographic routing protocols as packets need to be authenticated.

Limitations of LEAP

The main disadvantage of LEAP is that each node needs to store 4 types of keys. The density of the network is directly proportional to the computation and communication overhead. The other disadvantage is that the entire network is compromised when the unique global key is compromised during the initial key setup phase.


TinySec (Sastry 2004) is link layer security architecture for sensor networks. It provides three security goals which are authenticity, integrity and confidentiality while minimizing the use of computing, memory usage and bandwidth. Conventional security protocols have 16 or 32 bytes of overhead. However, sensor network cannot afford this overhead due to its limited resources. Therefore, TinySec has been implemented to address the security issues in wireless sensor networks. TinySec provides two modes of operation: TinySec-Auth and TinySec-AE. TinySec-Auth caters for origin and message authentication only and TinySec-AE provides authentication and encryption. TinySec can be easily integrated into different application and increases the likelihood of secure sensor applications.

Compared to end-to-end security where packets are encrypted by the sender and decrypted by the receiver, TinySec uses link-layer security where each transmission of the packets gets encoded and decoded at every node. End-to-end security mechanisms are vulnerable to DoS attacks. If integrity of a message is checked only at the base station, adversaries may inject illegitimate packets in the network and this may be routed through the entire network wasting precious energy and bandwidth. Sensor networks applications have a many-to-one architecture as all sensors transmit their readings to the base station. Many sensor nodes may sense same readings. Duplicate messages from different sensors are dropped so as to maximize the lifetime of the network. Link-layer architecture caters for duplicate messages and also detects tampered packets. This is achieved by in-network processing which required intermediate nodes to access, modify and delete contents of messages.

Link Layer Security

Link Layer security mechanism in sensor networks is achieved by access control, message integrity and message confidentiality.

Access Control

Access control helps to prevent unauthorized parties from participating in the network. Packets from unauthorized nodes should be rejected by legitimate nodes.

Message Integrity

If a message is modified in transit by an adversary, then it should be detected by the receiver.

Message Confidentiality

Information need to be kept private from unauthorized parties. Message confidentiality is achieved by using an encryption scheme.

Replay Protection

Adversary eavesdrop a legitimate message and replay it afterwards. Replay attack can be detected by associating an increasing counter with every message and reject messages with old counter values. However, each node must maintain a table of the last received counter value. This can be a problem for RAM-constrained sensor nodes. Replay attacks from different sensor nodes from different location can fill up the table. Therefore, this type of protection is not feasible for large sensor networks.

Access control and message integrity are obtained by including a message authentication code (MAC) with each packet.

TinySec Design

TinySec can be categorized into two modes of operation. The two different security modes are authentication only (TinySec-Auth) and authenticated encryption (TinySec-AE). In TinySec-Auth, the entire packet is authenticated with a MAC but the data is not encrypted. TinySec-AE encrypts the data packet which is authenticated with a MAC. After the data has been encrypted along with the packet header, the MAC is then computed.

TinySec packet format

TinySec is implemented in TinyOS which is an event-driven operating system designed for sensor network applications. The packet format for TinyOS, TinySec-Auth and TinySec-AE is shown in the figure below.

Figure 1

The common fields found in the above packets are as follows:

Dest - Destination address (2 bytes)

AM - Active Message handler ID (1 byte)

Len - Message length (1 byte)

Grp - Group ID (1 byte)

Data - Payload (maximum 29 bytes)

CRC - used to detect transmission errors. The 2 bytes CRC is computed over the packet and sent along with the packet. Receiver will re-compute the CRC and check it with the CRC field in the packet. If they are equal, the packet is accepted else receiver rejects it.

AM: active message type, similar to port numbers in TCP/IP. It specifies the appropriate handler function for the extraction and interpretation the message on the receiver side.

These fields are sent unencrypted so as to minimize consumption of energy. A sensor node may switch to low energy mode after determining that the message is not addressed to it. If the address and AM type are encrypted, receiving nodes will have to decrypt these fields. This wastes power. Encrypting the length field adds little to security since the length of message can be inferred regardless.

To detect transmission errors, TinyOS computes a 16-bit cycle redundancy check (CRC) over the packet. Receiving node will re-compute the CRC and check it with the CRC field in the packet. If they are equal, the packet will be accepted else it will be rejected. However, CRCs does no provide security against malicious modification or tampering of packets.

In order to guarantee message integrity and authenticity, the CRC field is replaced by a 4-byte MAC. The MAC protects the whole packet, including the destination address, AM type, length, source address and counter (for TinySec-AE), and the data (encrypted for TinySec-AE and unencrypted for TinySec-Auth). The CRC field is removed as a MAC can detect message injection and transmission errors. TinyOS packet format contains a group field which contains the ids of different sensor networks. The group field is mainly used to prevent interference with different sensor networks. The use of a shared authentication key allows the TinyOS group field to be dropped.

Integrity and Authentication in TinySec-Auth

This mode is always switched on by default in TinySec. Message Authentication Code (MAC) provides authenticity and integrity in a message. TinySec-Auth requires the sender and receiver to share a secret key to compute the MAC under a cryptographic process. The sender node first computes a MAC over the data and appends to it. The receiver re-computes the MAC and compares it with the received MAC. The data is accepted if both MACs are equal. If the computed MAC value does not match, the receiver will reject the packet. TinySec-Auth allows for only 1 byte of additional communication overhead.

Figure 2

As show in the figure above, a 4-byte MAC is constructed by encrypting a message with a block cipher in cipher block chaining (CBC). This method to generate a MAC from CBC is commonly known as CBC-MAC.

Conventional security protocols use MACs of 8 or 16 bytes. However, the authors of TinySec claim that a 4-byte MAC meets the requirements for WSN. Adversaries have a 1 in 232 chance of forging a MAC for a particular message. To be successful, adversary must send messages to the target recipient and wait for an acknowledgement. The wireless medium of WSNs allows only for a maximum of 40 forgery attempts per second. It would take over 20 months to send all the 232 MAC combinations. All power on the receiving node will be drained rendering this attack as useless. In such case, nodes could signal the base station when the threshold of unsuccessful MAC failures is reached or when it is subjected to DoS attacks.

Authentication and Encryption in TinySec-AE

In TinySec-AE, authentication is provided by MAC and semantic secure encryption by selecting an encryption scheme and specifying the IV format. Unlike TinySec-Auth where the MAC is generated from the data payload, TinySec-AE computes the MAC over the encrypted data and the packet header. It ensures that data is received from a trusted node and prevents adversaries from seeing data.

Most sensor application in WSN operates by reporting events occurring in surrounding conditions. For example if a node is only sending TRUE or FALSE, an adversary could decode the encrypted message part of YES and NO as they will be the same all the time. The solution resides in yielding different cipher text when encrypting the same plaintext twice. Initialization vector (IV) adds this variation when encrypting plaintext. IV is sent unencrypted as it is used in the decryption process. The structure of IV is shown below:

Dst || AM || L || src || ctr

Dst (2): destination address

AM (1): Active Message handler

L(1): Length of data payload

Src (2): Source address of sender

Ctr (2): Counter which increases by 1 after each message sent

The total length of an IV packet is 8-byte. It adds only 4-byte to the original value since dst and AM are already used in TinyOS packet. The new elements added are src and ctr which sums up to 4-byte.

TinySec authors make use of Cipher block chaining (CBC) as encryption scheme. CBC is designed to be used with random IV's. Moreover, if two plaintexts P and P' are encrypted with the same IV under CBC mode, the resulting ciphertexts will only reveal the length (in blocks) of the longest shared prefix of P and P'. That means that CBC leaks only a small amount of information in the presence of repeated IV's. IV in TinySec is used in counter mode, which can reveal partial information about the plaintext. The solution is to pre-encrypt the IV before XOR-ing it with the first part of the plaintext. Also, ciphertext stealing [] is used which ensures that the length of the ciphertext is the same as the plaintext. Therefore, transmitting ciphertext data will result in no loss of energy. The default block cipher in TinySec is Skipjack.

Limitations of TinySec

By default, a shared key is pre-loaded in every node. This key is used to generate MAC in order to authenticate packets. It only provides a baseline level of security. It is defenseless against node capture attack which is proven to be an easy process (Hartung 2005). A compromise node can reveal the secret key to an adversary. This can be used to gain access to information on the network. Also, the network may be vulnerable to injection attacks as the MAC of an adversary and a legitimate node would be the same.

TinySec adds up to 4 bytes of overhead to WSN packets causing more processor and battery power to be consumed. Also, TinySec does not address packets which are less than 8 bytes. CBC mode uses a block cipher of k-byte to encrypt the message. Messages less than 8 bytes will require at least one block of ciphertext since ciphertext stealing mechanism is done on a block basis. This increase in length would cause extra communication power cost.