TinySec: A Link Layer Security Architecture for Wireless Sensor Networks C. Karlof, N. Sastry, D....
-
date post
18-Dec-2015 -
Category
Documents
-
view
235 -
download
2
Transcript of TinySec: A Link Layer Security Architecture for Wireless Sensor Networks C. Karlof, N. Sastry, D....
TinySec: A Link Layer Security Architecture for Wireless Sensor Networks
C. Karlof, N. Sastry, D. Wagner
SPINS: Security Protocol for Sensor Networks
A. Perrig, R. Szewczyk, V. Wen, D. Culler, J. D. Tygar
Sensor Networks Many important applications, e.g.,
habitat monitoring, rescue operation, battle field monitoring
Without adequate security, wide deployment might be impossible Severe energy, resource constraints Take advantage of the constraints
Even a powerful adversary is limited to a small number of packets per unit time to inject or eavesdrop due to the limited wireless bandwidth, e.g., 19.2Kbps
Software implementation is possible
Motivation for Link Layer Security End-to-end security, e.g., SSH, SSL, or
IPSec, in conventional networks Message integrity is only checked at the
destination Dominant traffic is end-to-end
Dominant traffic is many-to-one in sensor networks Intermediate nodes need to access and
aggregate data End-to-end security is subject to DoS attacks
Relay a packet injected by an adversary wasting energy
Non-Issues
Denial of Service Attacks Jamming Resource Consumption Attacks Wormhole attacks …
Physical Tampering
Design Goals Message authentication (integrity)
MAC (Message Authentication Code): Secure checksum
Confidentiality Encryption
Symmetric key system TinySec uses a network-wide master key and
message authentication key SNEP of SPINS adopts a secret key between the
base station and a sensor node Optional
Authenticity & Confidentiality: SNEP (Part of SPINS)
Replay protection Semantic security
Encrypting the same plaintex twice should give two different cyphertexts
Use a unique IV (Initialization Vector) for each invocation of the encryption algorithm
Weak freshness Just order the messages, but cannot guarantee A is responding
to B’s request Low communication overhead
Counter values kept at each end point; no need to include in each message
Counter mode encryption & decryption
Ctr + K -> one-time pad
CBC MAC
Same code for encryption & MAC Save storage Semantic security: IV, e.g., counter, is not
reused
Strong freshness
Strong freshness, e.g., for counter synchronization
TinySec Design Goals Efficiency
Minimal communication, computation & memory overhead
Ease of Use 50% - 80% of 802.11 networks without any cryptographic
protection TynySec= true in the Makefile Right set of APIs Easy to use & customize considering the application
needs Portability
Included in TinyOS (& TOSSIM) TinyOS runs on a number of platforms including Texas
Instruments, Atmel, Intel x86, and StrongArm
TinySec Design
TinySec-AE: Authenticated encryption Encrypt the payload and compute the
MAC over the packet header and encrypted data
TinySec-Auth: Authentication only Authenticate the entire packet with a
MAC, but the data is not encrypted
Packet format
• TinySec-Auth only increases the msg size by 1 bytes• TinySec-AE increases it by 5 bytes
Security Analysis
4 byte MAC 232/2 = 216 trials to forge
Key space is reduced by squqre root due to birthday paradox
Not enough for security in conventional networks
On 19.2kbps channel, only 40 trials/s are possible => 20 months!
Adversary has to send it to an authorized receiver
Confidentiality Counter If there are n nodes and 16 bit
counter is used, an instance of IV is reused after n*216 packets
19.2Kbps, one packet per minute per node
IV is reused after 45 days Redistribute a new symmetric key
Encryption Cypher independent Symmetric key algorithms
Asymmetric algorithms are several orders of magnitude slower
Exception: elliptic curve alg. (ecTinyOS)
Time to execute cipher operations on the Mica2 sensor nodes (block cipher algorithms)
Byte time Time to transmit one byte 0.42ms on Mica2 TinySec-AE increases latency by 8% TinySec-Auth increases it by 1.5%
Keying Mechanism Determine how cryptographic keys are distributed and shared
throughout the network Use different keys for different applications
Use separate keys for encryption and message authentication Network-wide keying
Simple Vulnerable to node capture
Per-link keying Graceful degradation in the presence of compromised nodes Key distribution protocol is needed Passive participation & local broadcast are impossible
Per-group keying Graceful degradation in the presence of compromised nodes Key distribution is required Supports passive participation & local broadcast
Node-to-Node Key Agreement in SPINS
Secure key agreement Strong key freshness Most comm done by the base station
Authenticated Broadcast in SPINS - uTESLA
Generally, authenticated broadcast requires an asymmetric mechanism
Symmetric schemes are not secure Any receiver with the MAC key can
impersonate Asymmetric schemes are too
expensive Requires 50 – 1000 bytes/packet for
signature
Authenticated Broadcast in SPINS (Cont’d)
Delayed key exposure A node has to buffer the received data until
it receives the next key to verify the current key
Authenticated Broadcast in SPINS (Cont’d)
Sender chooses the last key Kn randomly and generate successive keys by successively applying a one way function F, e.g., MD5
In time interval t, sender uses Kt to authenticate the message
Sender releases Kt after intervals after the end of the time interval t
Implementation TinySec in 3000 lines of nesC code Requires 728 bytes of RAM and 7146 bytes of
program space 256 bytes of RAM & 8152 bytes of ROM
Modify TinyOS 1.1.2 radio stack to redirect byte level radio events to the TinySecM module
Modification of the scheduler Signal TinySecM when the MAC layer successfully
acquires the channel Begin the cryptographic computations Assign high priority to cryptographic operations
Evaluation
Packet size increase Fixed
Extra computation time & energy needed for cryptography Vary depending on implementation
Expected Latency Caused by TinySec
Time to Execute Cipher Operations
Energy Consumption (to send 24 bytes)
Bandwidth
#Senders
Total #received packets/sec
End-to-end latency
#hops
E2E delay (ms)
Questions?