Security on Sensor Networks
SPINS: Security Protocol for Sensor Networks
TinySec: Security for TinyOS
Presented by Min-gyu Cho
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 = 11000 instructions
Asymmetric Cryptography Very Expensive!!!
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
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: KAB KBA
– MAC keys: K'AB K'BA
– Counters: CA CB
• Counter exchange protocol
A  B: CA
B  A: CB, MAC(K’BA, CA || CB)
A  B: MAC(K’AB, CA || CB)
SNEP Protocol Details (Cont.)
• To send data D, A sends to B:
A  B:
{D}<K , C >
AB A
MAC( K'AB , [CA || {D}<K
]
,
>
C
A
AB
)
• To add the freshness for B’s response
A  B:
B  A:
NA, RA
{RB}<K , C >
BA B
MAC( K‘BA , [NA || CB || {RB}<K
]
,
>
C
B
BA
)
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
Broadcast Authentication
• Broadcast is basic communication mechanism
• Sender broadcasts data
• Each receiver verifies data origin
Alice
M
Sender
M
Bob
M
M
Carol
Dave
Simple MAC Insecure for Broadcast
K
Sender
M, MAC(K,M)
K
Alice
M, MAC(K,M)
Bob
M', MAC(K,M') K
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
 Authentication of P1: MAC(K5, P1 )
Authenticate K5
K3
F
K4
F
Time 4
K5
Time 5
F
K6
Time 6
F
K7
Time 7
P1
P2
K3
K5
Verify MAC
t
TESLA Quick Overview II
• Perfect robustness to packet loss
Authenticate K5
K3
F
K4
Time 4
P1
F
K5
K6
Time 5
Time 6
K7
Time 7
P2
P3
P4
P5
K2 K2
K3
K4
K5
Verify MACs
t
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
K {0,1}k
Ek : {0,1} 
{0,1}
n
n
• 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 (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
m1
m2
Ek
Ek
c1
c2
iv
Ek
CBC-Mode
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
K {0,1}k
MAC: {0,1} 
{0,1}t
m
m1
m2
length
– Can detect both malicious changes and
random errors
Ek
Ek
– Replaces CRC
– Can be built using a block cipher
– MAC key should be different
CBC-MAC Mode
than encryption key
Ek
MAC
TinyOS System Changes
TinySec
MicaHighSpeedRadio
CBC-MAC
CBC-Mode
RC5
Packet Format
dest
AM Grp
_ID
2
1
dest
AM
2
1
Encrypted
MAC’ed
length
1
data
CRC
2
1
IV
length
4
1
• Key Differences
No CRC
No group ID
MAC
IV
• Total:
data
MAC
4
-2 bytes
-1 bytes
+4 bytes
+4 bytes
+5 bytes
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
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 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