Security on Sensor Networks Presented by Min-gyu Cho SPINS: Security Protocol for Sensor Networks TinySec: Security for TinyOS SPINS: Security Protocol for Sensor Networks TinySec: Security for TinyOS

General Security Requirements Confidentiality: –The property that information is not made available or disclosed to unauthorized individuals, entities or processes Authentication –The verification of a claimed identity Integrity –The assurance that information can only be accessed or modified by those authorized to do so

Resource Constraints Limited energy Limited computation (4 MHz 8-bit) Limited memory (512 bytes) Limited code size (8 Kbytes) –~3.5 K base code (“TinyOS” + radio encoder) –Only 4.5 K for application & security Limited communication (30 byte packets) Energy-consuming communication –1 byte transmission = instructions Asymmetric Cryptography Very Expensive!!!

SPINSSPINS Adrian Perrig, Robert Szewczyk, Victor Wen, David Culler, J. D. Tygar, “SPINS: Security Protocols for Sensor Networks,” MOBICOM 2001 Security Protocols proposed for Sensor Networks which provides –Authentication Ensures data integrity & origin Prevents injecting bogus messages –Confidentiality Ensures secrecy of data Prevents eavesdropping

SPINS: Two Protocols SNEP –Sensor-Network Encryption Protocol –Secures point-to-point communication  TESLA –Micro Timed Efficient Stream Loss-tolerant Authentication –Provides broadcast authentication

System Assumptions Communication patterns –Frequent node-base station exchanges –Frequent network flooding from base –Node-node interactions infrequent Base station –Sufficient memory, power –Shares secret key with each node Node –Limited resources, limited trust

SNEP Security Goals Secure point-to-point communication –Confidentiality, secrecy –Authenticity and integrity –Message freshness to prevent replay Why not use existing protocols? –E.g. SSL/TLS, IPSEC

Basic Crypto Primitives Code size constraints  code reuse Only use block cipher encrypt function –Counter mode encryption –Cipher-block-chaining message authentication code (MAC) –Pseudo-Random Generator

SNEP Protocol Details A and B share –Keys The master secret key χ derived keys from the master secret key –Encryption keys: K AB K BA –MAC keys: K' AB K' BA –Counters: C A C B Counter exchange protocol A  B: C A B  A: C B, MAC(K’ BA, C A || C B ) A  B: MAC(K’ AB, C A || C B )

SNEP Protocol Details (Cont.) To send data D, A sends to B: A  B:{D} MAC( K' AB, [C A || {D} ] ) To add the freshness for B’s response A  B:N A, R A B  A:{R B } MAC( K‘ BA, [N A || C B || {R B } ] )

Secrecy & confidentiality –Semantic security against chosen ciphertext attack (strongest security notion for encryption) Authentication Replay protection Code size: 1.5 Kbytes Strong freshness protocol in paper SNEP Properties

Broadcast Authentication Broadcast is basic communication mechanism Sender broadcasts data Each receiver verifies data origin Sender Bob M Carol M DaveAlice MM

Simple MAC Insecure for Broadcast Sender Alice K K M, MAC(K,M) Bob K M, MAC(K,M) M', MAC(K,M')

 TESLA: Authenticated Broadcast Uses purely symmetric primitives Asymmetry from delayed key disclosure Self-authenticating keys Requires loose time synchronization –Use SNEP with strong freshness

 TESLA Quick Overview I Keys disclosed 2 time intervals after use Receiver knows authentic K3 K4K5K6K7 t Time 4Time 5Time 6Time 7 K3 P2 K5 P1 K3  Authentication of P1: MAC(K5, P1 ) FF Authenticate K5 Verify MAC F K6 F K5

 TESLA Quick Overview II Perfect robustness to packet loss K4K5K6K7 t Time 4Time 5Time 6Time 7 K3 P5 K5 P3 K3 P2 K2 P1 K2 Verify MACs P4 K4 FF Authenticate K5

 TESLA Properties Low overhead (1 MAC) –Communication (same as SNEP) –Computation (~ 2 MAC computations) Perfect robustness to packet loss Independent of number of receivers

TinySec: Security for TinyOS Included in TinyOS 1.x Link layer security mechanism, providing –Access Control –Integrity –Confidentiality –Transparency to applications and programmers

Block Ciphers Pseudorandom permutation (invertible) –DES, RC5, Skipjack, AES –Maps n bits of plaintext to n bits of ciphertext Block size n is typically 64 or 128 bits Key size k is typically 64 or 128 bits

Symmetric key encryption Confidentiality achieved by encryption Encryption schemes (modes) can be built using block ciphers –CBC-mode: break a m bit message into 64 bit chunks (m 1,m 2,..) –Transmit (c 1, c 2, …) and iv iv m2m2 m1m1 c1c1 c2c2 EkEk EkEk EkEk CBC-Mode iv is needed to achieve semantic security –A message looks different every time it is encrypted –iv reuse may leak information

MAC: Message Authentication Code Encryption is not enough to ensure message integrity –Receiver cannot detect changes in the ciphertext –Resulting plaintext will still be valid Integrity achieved by a message authentication code –A t bit cryptographic checksum with a k bit key from an m bit message –Can detect both malicious changes and random errors –Replaces CRC –Can be built using a block cipher –MAC key should be different than encryption key length m2m2 m1m1 MAC EkEk EkEk EkEk CBC-MAC Mode

TinyOS System Changes MicaHighSpeedRadio TinySec CBC-Mode RC5 CBC-MAC

Packet Format destAMIVlengthdataMAC Encrypted MAC’ed Key Differences No CRC -2 bytes No group ID -1 bytes MAC +4 bytes IV +4 bytes Total: +5 bytes 2111 destAM Grp _ID lengthdataCRC 2

UsageUsage Need to be aware of keys & keyfile –Currently, keys part of program, not intrinsic to mote (similar to moteID) –Makerules generates a keyfile if none exists and then uses it for programming all motes; –Keyfiles tied to a particular TinyOS installation. Manual transfer needed to install motes from different computers. Only application level code change: –Just use SecureGenericComm instead of GenericComm Works on Simulator

AnalysisAnalysis Access control and integrity –Probability of blind MAC forgery 1/2 32 –Industrial strength is usually 1/2 64 or less –Replay protection not provided, but can be done better at higher layers Confidentiality –Lots of ways to structure and manage IV’s, but IV reuse will occur after ~65000 messages from each node –For CBC mode, IV reuse is not as severe has other modes Does not necessarily leak plaintext –Common solution is to increase IV length  adds packet overhead