Security on Sensor Networks

1
Security on Sensor Networks
SPINS Security Protocol for Sensor
Networks TinySec Security for TinyOS

• Presented by Min-gyu Cho

2
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

3
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 11000 instructions
• Asymmetric Cryptography Very Expensive!!!

4
SPINS

• 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

5
SPINS Two Protocols

• SNEP
• Sensor-Network Encryption Protocol
• Secures point-to-point communication
• ?TESLA
• Micro Timed Efficient Stream Loss-tolerant
  Authentication
• Provides broadcast authentication

6
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

7
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

8
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

9
SNEP Protocol Details

• A and B share
• Keys
• The master secret key ?
• derived keys from the master secret key
• Encryption keys KAB KBA
• MAC keys K'AB K'BA
• Counters CA CB
• Counter exchange protocol
• A ? B CA
• B ? A CB, MAC(KBA, CA CB)
• A ? B MAC(KAB, CA CB)

10
SNEP Protocol Details (Cont.)

• To send data D, A sends to B
• A ? B DltKAB, CAgt
• MAC( K'AB , CA DltKAB, CAgt )
• To add the freshness for Bs response
• A ? B NA, RA
• B ? A RBltKBA, CBgt
• MAC( KBA , NA CB RBltKBA, CBgt )

11
SNEP Properties

• 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

12
Broadcast Authentication

• Broadcast is basic communication mechanism
• Sender broadcasts data
• Each receiver verifies data origin

Sender
Dave
Alice
M
M
M
M
Bob
Carol
13
Simple MAC Insecure for Broadcast
14
?TESLA Authenticated Broadcast

• Uses purely symmetric primitives
• Asymmetry from delayed key disclosure
• Self-authenticating keys
• Requires loose time synchronization
• Use SNEP with strong freshness

15
?TESLA Quick Overview I

• Keys disclosed 2 time intervals after use
• Receiver knows authentic K3

• Authentication of P1 MAC(K5, P1 )

K4
K5
K6
K7
K3
t
Time 4
Time 5
Time 6
Time 7
P1
K3
16
?TESLA Quick Overview II

• Perfect robustness to packet loss

K4
K5
K6
K7
K3
t
Time 4
Time 5
Time 6
Time 7
17
?TESLA Properties

• Low overhead (1 MAC)
• Communication (same as SNEP)
• Computation ( 2 MAC computations)
• Perfect robustness to packet loss
• Independent of number of receivers

18
TinySec Security for TinyOS

• Included in TinyOS 1.x
• Link layer security mechanism, providing
• Access Control
• Integrity
• Confidentiality
• Transparency to applications and programmers

19
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

20
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 (m1,m2,..)
• Transmit (c1, c2, ) and iv

• iv is needed to achieve semantic security
• A message looks different every time it is
  encrypted
• iv reuse may leak information

21
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

m2
m1
length
Ek
Ek
Ek
MAC
CBC-MAC Mode
22
TinyOS System Changes
MicaHighSpeedRadio
TinySec
CBC-Mode
CBC-MAC
RC5
23
Packet Format

• Key Differences
• No CRC -2 bytes
• No group ID -1 bytes
• MAC 4 bytes
• IV 4 bytes
• Total 5 bytes

24
Usage

• 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

25
Analysis

• Access control and integrity
• Probability of blind MAC forgery 1/232
• Industrial strength is usually 1/264 or less
• Replay protection not provided, but can be done
  better at higher layers
• Confidentiality
• Lots of ways to structure and manage IVs, 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