TinySec: A Link Layer Security Architecture for Wireless Sensor Networks Seetha Manickam

Overview  Motivation  TinySec-Introduction  Sensor Networks Security threats and Need for link layer security architecture design  Design goals  Tiny sec Design   Security Analysis of Tinysec   Performance Evaluation of Tiny Sec   Security flaws identified in standard for sensor networks

Motivation Sensor networks : Resource constraint networks – small memories, weak processors, limited energy… Conventional security protocols (802.11b, are found to be insecure, adds lot of overhead (16-32 bytes) ) Need for a new security architecture for sensor networks -TINYSEC

TINYSEC Light weight and efficient link layer security package Developers can easily integrate into sensor network applications. A research platform that is easily extensible and has been incorporated into higher level protocols.

Security threats in Sensor Networks Use of wireless communications -In a broadcast medium, adversaries can easily eavesdrop on, intercept, inject and alter transmitted data. Adversaries can Interact with networks from a distance by inexpensive radio transceivers and powerful workstations. Resource consumption attacks. Adversaries can repeatedly send packets to drain nodes battery and waste network bandwidth, can steal nodes. However, these threats are not addressed. Focus is on guaranteeing message authenticity, integrity and confidentiality

Motivation for Link layer security in Sensor Networks End-End security Mechanisms : Suitable only for conventional networks using end-end communications where intermediate routers only need to view the message headers. BUT, in Sensor networks In-network processing is done to avoid redundant messages-Requires intermediate nodes to have access to whole message packets and just not the headers as in conventional networks...contd..

Motivation for Link layer security in Sensor Networks Why end-end security mechanisms not suitable for sensor networks? If message integrity checked only at the destination, the networks may route packets injected by an adversary many hops before they are detected. This will waste precious energy. A link layer security mechanism can detect unauthorized packets when they are first injected onto the network.

Design Goals-Security Goals A link layer security protocol should satisfy three basic security properties: Access control and Message integrity - prevent unauthorized parties from participating Confidentiality - keeping information secret form unauthorized parties Explicit omission: Replay protection - an adversary eavesdropping a legitimate message sent b/w 2 authorized parties..replays it at a some time later

Design goals –Performance goals A system using cryptography will incur increased overhead in length of the message. Overhead limitations-REQUIRED Increased message length results- - decreased message throughput -increased latency -INCREASED POWER CONSUMPTION ( Sensor Networks  )

Design Goals-Ease of Use Security Platform- Higher level security protocols can use Tinysec to create secure pair wise communication between neighboring nodes. Transparency- Should be transparent to the user Portability- should fit into the radio stack so that porting the radio stack from one platform to another is a simple job.

Security Primitives Message Authentication code - A cryptographic checksum for checking the message integrity Initialization vector (IV) -A side input to the encryption algorithm.

TINYSEC-DESIGN 2 Security Options- 1.Authentication Encryption ( Tinysec-AE) 2. Authentication only (Tinysec-Au) Encryption :  Specifying the IV format  Selecting an encryption Scheme

Tinysec IV format IV too long- add unnecessary bits to the packet Too short – Risk of repetition How long should be the IV? N bit IV repeat after 2^n +1. If we use a n bit counter repetitions will not happen before that point.

Encryption schemes CBC is the most appropriate scheme for sensor networks –why? Works better with repeated IVs. IVs can be pre encrypted for use since it is proved that CBS mode is highly secure with non repeated IVS. One drawback- Message expansion  Use Cipher text stealing-Cipher text length=plaintext length

Message integrity Authentication is very Important in Sensor networks ( Encryption is optional, though!) Confidentiality is only necessary when something needs to be kept secret. Consider the case of burglar alarm- Encryption is unnecessary for an alarm signal, but it is undesirable to have it from an adversary.

TinySec packet Format

Security Analysis of TinySec Message Integrity and Authenticity Security of CBC-MAC is proportional to the length of the MAC. Is the choice of 4 byte MAC- less secure then? – NO!!!!!..Not for sensor networks! Given 4 byte MAC- adversary should make at least 2^31 tries. Even if the adversary flood the channel, he can send only 40 forgery attempts/sec, sending 2^31 would take 20 months. Battery operated nodes do not have that much energy to collect all those packets.

Confidentiality analysis for Tinysec Combination of carefully formatted IVs, low data rates and CBC mode for encryption achieves high confidentiality in TinySec. The format of the last 4 bytes –maximizes the number of packets each node can send before there is a repetition of IV. For a network of n nodes, n.2^16 packets will be sent before the reuse of IV.

Performance Evaluation of TinySec Increases the computation costs and the energy cost of sending a packet, but these costs must be modest compared to the security that Tinysec provides.

Keying mechanism –contd. Use per-link keying, separate Tinysec key for each pair of node wishing to communicate. Drawback: Key distribution becomes a challenge. Allow a group of nodes to share a TinySec key rather than each pairs. Group keying provides an intermediate level of resilience.

Keying Mechanisms Appropriate keying mechanism for a particular network depends on several factors. Tinysec key- A pair of skipjack key-one for authentication, one or encryption. Simplest keying mechanism: Use a single key for the entire network, Preload the key before deployment.-Adversary can compromise on node and get the key.. 

Implementation of TinySec Implemented on Berkeley sensor nodes. Integrated into TOSSIM simulator lines of nesC code. TinyOS radio stack modified to incorporate TinySec. Level of protection can be included in the data payload.

Performance Evaluation of TinySec Increases the computation costs and the energy cost of sending a packet, but these costs must be modest compared to the security that Tinysec provides.

Performance summary The energy, bandwidth and latency overhead –all are less than 10% by using Tinysec. Overhead-due to the increased packet size for cryptography. Tinysec is very competitive with other solutions. Tinysec has gathered a number of external users.

Insecurity of Where is Security in ? Handled by the Media access control layer The application controls the security required By default – “NO Security” Four types of packets –Beacon, Data, ACK, Control packets for MAC Layer NO Security for ACK packets The other packets can optionally use encryption or integrity checks

How does it work? Application decides the choices on the security level. (A bool value) Access Control Lists are used to enforce these security levels (max up to 255 entries) If security is enforced then the MAC layer looks up the ACL table for the cryptographic material for the destination

Security Suites No security – NULL AES-CTR - Encryption only, CTR Mode AES-CBC-MAC – MAC only (options of 32bit, 64bit and 128bit MAC’s) AES-CCM – Encryption and MAC (options of 32bit, 64bit and 128bit MAC’s) Replay protection can be turned on or off for any of the above

Cont’d On packet reception, based on the flags the MAC layer decides how to process the packet ACL Entry Format

Details of Security Suites NULL – no security, mandatory in all chips AES-CTR (Confidentiality alone) –Break plain text into 16-byte blocks p 1,…,p n –Compute cipher text c i = p i xor E k (x i ) –CTR or Nonce x i is necessary for the receiver to decrypt

Nonce Is made up of –Static flags field –Sender’s address –3 counters 4 byte frame counter (identifies the packet) 1 byte key counter 2 byte block counter (numbers the 16 byte blocks in a packet)

More on Nonce Frame counter controlled by the hardware radio –Sender increments it after every packet –When reaches max value no further encryptions are possible Key counter – application’s control –Used when frame counter has reached its max value Goal of frame and key counter is to prevent nonce reuse (in a single key’s life-time) Use of block counter –ensure different nonce’s are used for each block –need not be transmitted

AES-CBC-MAC Sender has options of 4, 8 or 16 byte MAC Communicating parties have to share a key

AES-CCM Applies CBC-MAC over the header and the data Encrypts the data MAC on both using AES-CTR mode

Replay Counter Applicable to AES-CTR and AES-CCM suites The replay counter is 5 bytes long –Frame counter –Key Counter (MSB) Note: This is same as the nonce but is used for a different purpose.

Problems Three classes –Nonce management –Key management –Integrity protection

Nonce Problems Same Key in Multiple ACL entries –If used, very likely that nonce is also reused –This could break the confidentiality Simple solution –If using the same key then use only one ACL entry, after sending the first packet, change the ACL entry (the software must keep track of which destinations are in play)

Nonce Problems Loss of ACL – Power Failure –Assuming that the ACL is restored, what about the nonces? –The authors say that the lacks clarity in this issue Recommendation – re-key after power failure Related issue – what happens when the node is sleeping Again there is presumably no clarity in the specification

Key Management Problems No group keying –First approach: Assign different ACL entries for all the nodes in the group and use the same key (Nonce management problem, ACL will be large) –Second approach: Single ACL entry – heavy, since for every destination the ACL has to be changed. Assuming the receivers also employ the same strategy then the receiver must switch the ACL before a packet arrives from a destination other than that in the current ACL

Key Management Problems Replay protection is incompatible with group keying –Node x transmits 100 messages, so replay counter is at 99 now –Node y starts transmission, its replay counter is going to 0, so the packets are dropped.

Nonce and Replay Counter Nonce is bound to the key – incremented with every message that is sent should use a different nonce (if two different entries use the same key, they share a nonce) Replay counter is bound to the sender’s address. If two ACL entries share a key, they still have different replay counters.

Integrity protection Problems Unauthenticated encryption –Recommendation – do not use AES-CTR DoS on AES-CTR –Two parties X and Y communicating (Replay protection is enabled) –Attacker sends a very high value for the key and frame counter with garbage with sender ID X –This would cause the messages from legitimate sender to be dropped.

Integrity protection Problems ACK without MAC –Sequence number sent in clear –Adversary can send ACK’s

Conclusions We have learnt that there are design vulnerabilities in the conventional protocols for sensor networks. Conventional protocols tend to be conservative in their security guarantees, typically adding bytes of overhead. Tinysec addresses these with extreme careful design and takes advantages of the limitations of sensor networks.

References Chris karlof, Naveen Sastry, David Wagner,”TinySec: A Link Layer Security Architecture for Wireless Sensor Networks,” Proceedings of the 2nd international conference on Embedded networked sensor networks, p , 2004 Naveen Sastry and David Wagner, “Security Considerations for IEEE Networks”. ACM Workshop on Wireless Security WiSe 2004, October 2004

Extra slides

Take - away Specification writers –Warn against Dangerous ACL configurations –Better support for various keying models –Do not support AES-CTR –Authenticated ACK

Take - away Application Designers –Do not use AES-CTR –Do not rely on ACK Hardware Designers –Support for 255 ACL entries (depends on the size of the network) –Retail ACL in low power mode (if possible nonces too) –Do not support AES-CTR