wsn security (background)
Post on 19-Jan-2015
8.025 Views
Preview:
DESCRIPTION
TRANSCRIPT
WSN: SECURITY
Peter ChapinAbe Barth-WerbRob RohrDiana Tatar
CS295/361Wireless Sensor NetworksFeb. 12, 2008
Agenda Security Overview
Peter Chapin
Simulation Environment – TOS1.xAbe Barth-Werb
TinySec – TOS1.xRob Rohr
MiniSec – TOS2.xDiana Tatar
WSN Security(Background)
Peter C. Chapin
Security Services, Part 1 Confidentiality
Keep data from unauthorized eyes (encryption) Authentication
Only accept packets from authorized senders (MAC, not expensive digital signatures)
Data Integrity Ensure packets not maliciously modified in
flight (MAC replaces normal CRC). BUT... don't interfere with in-network data
aggregation (so no end-to-end protection).
Security Services, Part 2 Anti-Replay
Reject authenticated packets that are “replayed” by an adversary to confuse the network. Can't keep arbitrary amounts of information about
past packets. One approach: label each outgoing packet with a
counter. Receiver ignores old labels. TinySec does nothing to protect against replays.
Authors argue this is outside the scope of the link layer.
Other Kinds of Attacks Traffic Analysis
A concern when the fact communication has taken place is itself revealing.
Normally thwarted by generating spurious traffic. Obvious this is undesirable in a WSN
Denial of service Keep nodes busy with many queries. Prevents
nodes from engaging in normal activity. Sleep Deprivation
A form of denial of service specifically intended to wear down batteries.
Special Challenges, Part 1 Small Computational Resources
Public key methods too computational intensive (even ECC is too hard).
Symmetric algorithms must be selected carefully Must be easy to compute Must have small memory footprint (instruction and
data) No space for large arrays of pre-computed data.
Skipjack seems favored by some researchers. MiniSec authors used OCB mode
Computes MAC and cipher text in a single pass.
Special Challenges, Part 2 Extremely Powerful Adversaries
Adversary not limited to mote technology! Can use a cluster of workstations to crack
security in recorded packets. Can use powerful antennae and transceivers
to interact with WSN from a “safe” distance. BUT...
WSN can't send/receive packets too quickly. Hard for adversary to collect data or execute
trial-and-error style attacks.
Special Challenges, Part 3 No Physical Security!
Adversary who steals a mote can: Manipulate sensors to generate bogus data. Attempt to extract key material from it.
Countermeasures: Tamperproof packaging
Does it really exist? Key revocation protocols
Not all applications suffer from a lack of physical security.
Special Challenges, Part 4 Low Power Operation
Must minimize radio overhead. Can't bulk up packets with security headers.
Large IVs, large nonces, long time stamps... All bad.
Must use clever techniques to minimize packet size Pack bits into other header fields Maintain synchronized state on two
communicating motes; use headers only to keep synchronized.
Key Distribution How do the nodes get the keys?
Use a single, network-wide key Simple to deploy Allows easy network auto-configuration and
self-healing. BUT... a single node compromise breaks the
network. Use a different key for each communicating
pair Introduces a key distribution problem. Lots of research on this.
Probabilistic Key Sharing
“A Key Management Scheme for Distributed Sensor Networks”Eschenauer and Gligor, CCS '02
Each node has kkeys drawn randomlyfrom a pool of size P
Shared keys
Radioconnectivity
SNEP / TinySec / MiniSec SNEP
Oldest of the three Relatively high packet overhead (8 bytes)
TinySec Leaves out key distribution and anti-replay
MiniSec Provides anti-replay support using synchronized
counters. But uses clever methods to keep counters in synch
OCB mode for faster MAC + ciphertext computation.
TinyOS Simulation EnvironmentTOSSIM, TinyViz
Abe Barth-Werb
BEWARE!Tiny OS 1 ONLY!!!
Cool stuff from 40,000 feet Radio Loss Simulation
Lossy builder Packet Injection
SerialForwarder TOSSIM Power TinyViz
TinyViz plug-ins
DEMO-O-CLOCK!!!!
TINYSECAN OVERVIEW
It’s tiny. Really.And somewhat secure.
Rob Rohr
TinySec Architectural Features Single shared global cryptographic
key Link layer encryption and integrity
protection transparent to applications New radio stack based on original
Cryptography based on a block cipher
KKK
TinySec Summary Security properties
Access control Integrity Confidentiality
Performance 5 bytes / packet overhead Peak bandwidth (8 bytes data):
25 packets/sec vs. 40 packets/sec (TinySec) (MHSR)
Block Ciphers Pseudorandom permutation
(invertible) DES, RC5, Skipjack, AES Maps n bits of plaintext to n bits of
ciphertext
Used to build encryption schemes and message authentication codes (MAC)
nKnk
k
E }1,0{}1,0{: }1,0{
Packet Format
Key DifferencesNo CRC -2 bytesNo group ID -1 bytesMAC +4 bytesIV +4 bytes
Total: +5 bytes
dest
AM IV
len
gt
h data MAC
2 1 4 1 4
Encrypted
MAC’ed
TinySec Interfaces
TinySec TinySecM: bridges radio stack and crypto libraries
BlockCipher 3 Implementations: RC5M, SkipJackM,
IdentityCipher (SRI has implemented AES)
BlockCipherMode CBCModeM: handles cipher text stealing
No length expansion when encrypting data MAC
CBCMACM: computes message authentication code using CBC
MHSRTinySecM
TinySecM
CBC-ModeM
RC5M
CBC-MACM
Security Analysis Access control and integrity
Probability of blind MAC forgery 1/232
Replay protection not provided, but can be done better at higher layers
Confidentiality – Reused IVs can leak information IV reuse will occur after 216 messages from each node
[1 msg / min for 45 days] Solutions
increase IV length adds packet overhead key update protocol adds complexity
Applications have different confidentiality requirements Need a mechanism to easily quantify and configure
confidentiality guarantees Applications may provide IVs implicitly (e.g.
timestamps) Apps may guarantee sufficient variability in their messages
Cipher Performance
2 block cipher operations per block, which take 1.0 ms/block For comparison, takes an ~4.8 ms to send one block over radio Encryption and MAC can be overlapped with
transmission/reception
Implementation
Block Operation Time (cycles)
Block Operation Time (ms)
RC5 C only ~5750 + 1.70 ms
RC5 SPINS: C + asm
~2775 avg 0.75 ms
SkipJack
TinySec: C only
~2500 0.70 ms
RC5 TinySec: C + asm
~1775 avg 0.50 ms
Discussion Short packets have more overhead
Min data size is 8 bytes (size of block cipher)
Packet length not affected for more than 8 bytes of data
Acknowledgments can be authenticated with no extra work or overhead 1/256 chance of forgery
Group ID no longer supported
Usage: How does this change my life? 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, used for programming all motes;
Keyfile resides in user’s home directory. Manual transfer needed to install motes from different computers.
Only application level code change: Just use SecureGenericComm instead of GenericComm
Works in simulator
Conclusions TinySec can provide transparent
security for applications Access control Integrity Confidentiality
Problems not addressed: Jamming Node or key compromise Replay Denial of service
MINISEC:A SECURE SENSOR NETWORK COMMUNICATION ARCHITECTURE
Developed by Carnegie Mellon University
Diana Tatar
Goal: Design a secure sensor network
communication protocol that provides Data secrecy Authentication Replay protection Freshness
Low energy consumption Resilient to Lost Messages
Comparison
Energy Consumption
Low High
Low
High
Secu
rity
ZigBee
TinySec
MiniSec SPINS
MiniSec-U: Unicast Communication
Offset Codebook Mode (OCB) - Encryption Block cipher mode of operation Authenticated encryption in a single pass
OCB
Plaintext
Ciphertext MAC/Tag
OCBKey
IV/Nonce
CiphertextMAC/Tag
Plaintext Error Initialization vector (IV) ensures that same
plaintext does not encrypt to same ciphertext Needs to be non-repeating An incrementing counter is used
KeyIV/Nonce
Method 1: Send IV with Packet
E
Plaintext
KeyIV
CiphertextMAC/Tag
D KeyIV
CiphertextMAC/Tag
Plaintext
Ciphertext TagIVTinySec
20 – 30 bytes2 bytes
Disadvantage: ~ 10% packet overhead
Method used by TinySec
Method 2: Synchronized IV
SPINS IV kept as incrementing counter on both parties Advantage: Eliminate IV in each packet sent Disadvantage: Counter resynchronization
IV = 2 IV = 2
CiphertextTag
CiphertextTag
CiphertextTag
IV = 3
IV = 1 IV = 1IV = 0 IV = 0
Resynchronize Counter, IV=3Tag
MiniSec-U: IV Management
IV management is core issue Strike a compromise to attain minimum
energy consumption Send last x bits of the IV
Low communication overhead Keep x low
No counter resynchronization Resynchronizes implicitly
Send partial IV(MiniSec)
Entire IV(TinySec, ZigBee)
None(SPINS)
IV Sent with Each Packet
Comparison
Pros Cons
TinySec No counter resynchronization
Low packet overhead
ZigBee No counter resynchronization
High packet overhead
SPINS No packet overhead Counter resynchronization
MiniSec No packet overhead Implicit counter resynchronization
MiniSec-B:Broadcast Communication Many-to-many communication
All nodes share symmetric key OCB-Authentication & Encryption Replay protection
Timing based – detect replays outside of timing window
Bloom filter – detect replays within timing window
TinySec: No protection
Ciphertext MACIV
Ciphertext MACIV
Disadvantage: No replay protection
SPINS and ZigBee: Per Sender State
IVAB = 1000 IVAB = 1000
Ciphertext1
IVAB = 1001 IVAB = 1001
BA C
IVBC = 0000 IVBC = 0000IVBC = 0001 IVBC = 0001
Ciphertext2
Disadvantage: Stored state grows at O(n)n is number of senders
Ciphertext1
MiniSec-B: Timing Based Approach
plaintext1
kOCBE1
ciphertext1, tag1
Ciphertext1Tag1
Time
E1
E3
E2
E1
E3
E2
Ciphertext1Tag1
OCBkE1
ciphertext1tag1
OCBkE3
ciphertext1tag1
MiniSec-B: Bloom Filter Based Approach
Bloom filter1
Counterca= 0
plaintext2
plaintext1
k OCBE1 || ca
ciphertext1, tag1
Time
E1 E1
Ciphertext1Tag1ca
MiniSec-B: Bloom Filter Based Approach
Bloom filter1
Counterca= 0
plaintext2
kE1 || ca
ciphertext2, tag2
OCB
plaintext1
k OCBE1 || ca
ciphertext1, tag1
Time
E1 E1
Ciphertext1Tag1ca
Ciphertext2Tag2ca
MiniSec-B: Bloom Filter Based Approach
Bloom filter1
Counterca= 0
plaintext2
kE1 || ca
ciphertext2, tag2
OCB
plaintext1
k OCBE1 || ca
ciphertext1, tag1
Time
E1 E1
Ciphertext1Tag1ca
Ciphertext2Tag2ca
Ciphertext2Tag2ca
ComparisonPros Cons
TinySec No counter resynchronization
No stored state
Packet overhead No replay protection
ZigBee No counter resynchronization
Replay protection
High packet overhead O(n) state
SPINS No packet overhead Replay protection
Counter resynchronization O(n) state
MiniSec No packet overhead Implicit counter resynch Constant state Probabilistic replay
protection
Loose time synchronization
Conclusion Existing protocols either optimize
for high security or low energy utilization
MiniSec Low energy consumption High security
Bibliography Team project web site
http://sharepoint.uvm.edu/sites/tinysec
WSN Security TBA
TinySec TinySec: A Link Layer
Security Architecture for Wireless Sensor Networkshttp://naveen.ksastry.com/papers/tinysec-sensys04.pdf
TinySec: User Manualhttp://www.tinyos.net/tinyos-1.x/doc/tinysec.pdf
MiniSec MiniSec: A Secure Network
Communication Architecturehttp://sparrow.ece.cmu.edu/group/minisec.html
Simulation TOSSIM: A Simulator for
TinyOS Networks http://www.cs.berkeley.edu/~pal/pubs/nido.pdf
TinyViz: TOSSIM and TinyVizhttp://webs.cs.berkeley.edu/retreat-1-03/slides/1-03-tossim-tinyviz.pdfAlso, TOS1.x Tutorial, Lesson 5
PowerTOSSIM: Efficient Power Simulation for TinyOS Applications (SenSys ’04)http://www.eecs.harvard.edu/~shnayder/ptossim/
top related