TinySec: A Link Layer Security Architecture for Wireless Sensor ...
TinySec: A Link Layer Security Architecture for Wireless Sensor ...
TinySec: A Link Layer Security Architecture for Wireless Sensor ...
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
<strong>TinySec</strong>: A <strong>Link</strong> <strong>Layer</strong><br />
<strong>Security</strong> <strong>Architecture</strong> <strong>for</strong><br />
<strong>Wireless</strong> <strong>Sensor</strong> Networks<br />
Chris Karlof, Naveen Sastr,<br />
David Wagner<br />
Presented By: Tristan Brown
Outline<br />
• Motivation<br />
• Cryptography Overview<br />
• <strong>TinySec</strong> Design<br />
• Implementation and Evaluation<br />
• Results
Motivation<br />
• Need a secure communications<br />
plat<strong>for</strong>m <strong>for</strong> sensor networks<br />
– Data is broadcast <strong>for</strong> all to hear.<br />
– <strong>Sensor</strong> network nodes have severely<br />
limited resources.<br />
– Can’t use existing architectures designed<br />
<strong>for</strong> powerful devices.
Cryptography Overview<br />
• Why use crypto<br />
• Provide probabilistic guarantees about<br />
messages sent/received on the<br />
network.<br />
– Access control/message integrity<br />
– Confidentiality<br />
– Replay Protection
Access Control/Message<br />
Integrity<br />
• Ensure only authorized senders are<br />
allowed to send messages.<br />
• Ensure messages are unmodified after<br />
transmission.<br />
• Can achieve both with a Message<br />
Authentication Code (MAC).
Message Authentication<br />
Codes<br />
• Essentially a keyed checksum of the<br />
message<br />
• Access Control: Cannot compute MAC<br />
without the key.<br />
• Message Integrity: Any change to the<br />
message invalidates the MAC.
Confidentiality<br />
• Keep message content from<br />
unauthorized viewers.<br />
• Semantic security: ideally should<br />
prevent adversary from learning<br />
anything about the encrypted message.<br />
• Achieved by message encryption with<br />
an Initialization Vector (IV)
Initialization Vector<br />
• Plaintext prefix to the encrypted<br />
message<br />
• Used to add variation to otherwise<br />
identical messages<br />
– Without, identical messages would encrypt<br />
identically, violating semantic security.
Replay Protection<br />
• Prevent a legitimate message from<br />
being resent later.<br />
• Can be achieved by a monotonically<br />
increasing message counter.<br />
• Not addressed by <strong>TinySec</strong>; authors<br />
believe higher layer protocols should<br />
handle this.
<strong>TinySec</strong> Design<br />
• Unsuitability of existing schemes<br />
requires a new design<br />
– High level protocols like SSL or IPSEC are<br />
too heavyweight.<br />
– Existing wireless security designs are still<br />
too limiting<br />
• Insecure (WEP)<br />
• Incomplete (SNEP)
Two-teir design<br />
• Based on the TinyOS Packet<br />
• <strong>TinySec</strong>-Auth replaces the CRC and<br />
group field with a MAC<br />
• <strong>TinySec</strong>-AE adds encryption to<br />
<strong>TinySec</strong>-Auth
Packet Format
MAC<br />
• Protects the entire packet (except the<br />
MAC itself).<br />
• Uses CBC-MAC with packet length<br />
XORed with the first block.<br />
• Store 4 bytes of the result.
MAC<br />
• Is 4 bytes secure<br />
– Requires 2 31 tries on average to brute <strong>for</strong>ce<br />
a single message.<br />
– Given a 20kbps channel would take 20<br />
months; far longer than a node lifetime.<br />
– Numerous MAC failures would give away<br />
the attacker.
MAC<br />
• Remove the CRC and group field to<br />
make room <strong>for</strong> the MAC.<br />
– Groups can be created by using different<br />
keys <strong>for</strong> the CBC.<br />
– MAC provides integrity protection making<br />
the CRC redundant<br />
– Result: MAC increases packet size by only<br />
1 byte.
Encryption<br />
• Two components<br />
– Initialization Vector<br />
– Cipher<br />
• Encrypt only the message<br />
– Allows nodes to per<strong>for</strong>m early rejection<br />
based on AM.
Initialization Vector<br />
• 8 byte IV<br />
– 4 bytes are taken from <strong>TinySec</strong>-Auth<br />
header fields<br />
– 2 bytes are source address<br />
– 2 bytes are a simple counter<br />
• Results in 4 byte packet size increase
Initialization Vector<br />
• How secure is this<br />
– Assuming all other header fields don’t<br />
change, takes 2 16 packets to repeat an IV.<br />
• At 1 packet/minute, will take 45 days to repeat<br />
an IV<br />
– Repeated IV leaks limited in<strong>for</strong>mation (due<br />
to cipher choice).<br />
– If cipher is rekeyed, repeated IV isn’t a<br />
problem.
Cipher<br />
• What kind of cipher should be used<br />
– Stream cipher<br />
• Use key and IV to generate keystream, XOR<br />
with data<br />
• If IV is repeated, can recover XOR of plaintexts.<br />
– Block Cipher (CBC)<br />
• XOR first block with IV, encrypt<br />
• For successive blocks XOR with prior<br />
ciphertext and encrypt.
CBC<br />
• In case of a repeated IV only leaks the<br />
similarity of the first n identical blocks.<br />
• Uses same cipher construct as CBC-<br />
MAC (save on code space)<br />
• Must not use same key <strong>for</strong> encryption<br />
and CBC-MAC!
Keying<br />
• Simple mechanism: use a single pair of keys<br />
<strong>for</strong> all nodes<br />
– Entire network vulnerable to a single-node exploit.<br />
• <strong>Link</strong> keying: use separate keys <strong>for</strong> every pair<br />
of nodes that communicates<br />
– Key distribution is complex<br />
• Group keying: Group nodes together, use<br />
different keys <strong>for</strong> each group.
Implementation and<br />
Evaluation<br />
• Implemented <strong>for</strong> TinyOS on Mica<br />
plat<strong>for</strong>m<br />
• Used skipjack as the block cipher <strong>for</strong><br />
CBC/CBC-MAC<br />
– Unencumbered by patents (unlike rc5)<br />
– High per<strong>for</strong>mance and secure.<br />
• Used single network-wide keypair <strong>for</strong><br />
simplicity.
Per<strong>for</strong>mance<br />
• Small throughput drop/latency rise consistent with the<br />
increased packet size<br />
• No other noticeable difference (all computation can<br />
be completed as the packet is transmitted/received)
Power Consumption
Results<br />
• Mostly effective<br />
authentication/encryption <strong>for</strong> sensor<br />
network environment<br />
– Reduced size IV/MAC offset by inability to<br />
exploit the network without severely<br />
impacting it (node death)<br />
– Some assumptions might not hold in all<br />
environments
Results<br />
• Open Problems<br />
– No keying mechanism (area of active<br />
research)<br />
– <strong>Security</strong> assumptions made based on node<br />
lifetime; keys may outlive nodes.