01.01.2015 Views

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 ...

SHOW MORE
SHOW LESS

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.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!