Security Tradeoffs

in NEST

1
 Administrative

• Project Title: Security Tradeoffs in NEST

• Program Manager: Vijay Raghavan
• PI Name(s): C. M. Krishna, Y.-H. Lee, K. G. Shin, A. Ganz, I.
Koren, and C.A. Moritz
• PI Phone Number(s): (413) 545-0766
• PI E-Mail Address(es): krishna@ecs.umass.edu
• Company/Institution: Univ of Massachusetts at Amherst, Univ of
Michigan, Arizona State University
• Contract Number: F33615-02-C-4031
• Award Start Date: 9/9/2002
• Award End Date: 9/9/2004
• Agent Name/Organization: Juan Carbonell, Wright-Patterson
Air Force Base.

2
 Subcontractors and Collaborators

• Subcontractors
– University of Michigan
– Arizona State University
• Collaborators
– University of Virginia
– BBN
– UC Berkeley
– SRI

3
PI Name
Affiliation Security Tradeoffs in NEST
University of Massachusetts; University of Michigan; Arizona State University
Problem and Challenge New Ideas
System
Constraints
Security
Requirements
Application
Needs
• Adapting security level of each task to
application requirements and system
constraints.
Middlewar

SERVICES Other Services

• Security Broker • Allocation • Security broker to select the
• Power Management • Scheduling appropriate security protocol.
• Failure Handling • Routing
• Intrusion Detection • …. • Fault-tolerance and performance
e

integrated with security

TinyOS

Impact Schedule
 Ensures appropriate levels of • Q4FY03
• Encryption mechanisms
security for application needs. • Incorporating fault-tolerance
 Integrates security with • Intrusion detection
• Secured wireless protocol
performance, reliability, power • Q2FY04 - Security Broker
requirements and constraints. • Q2FY04 - IV Manager
 Enables dynamic adjustments as • Q3FY04 - Software prototype
• Q4FY04 - Experimentation & validation
needs and resource availability
change.
4
 Problem Description/Objective

• NEST needs an integrated framework for a secure,

resource-constrained system
• To preserve resources, it needs to dynamically
determine appropriate security actions, given
– Application assurance requirements
– System state and configuration
– Operating environment (such as benign or hostile)

• Our project will enable NEST to

– Ensure appropriate security levels
– Integrate security with performance, power, and reliability
– Permit dynamic adjustments as needs/resources change

5
 Key Project Directions

• Manage Security Actions/Levels – Security Broker

– Coarse-grained: Pre-deployed security services
– Fine-grained: embedded Initialization Vector (IV) Manager
• Manage Key Updates
– Lightweight Security Protocol (LiSP)
• Provide Reliable Security
– Detect if faults are injected or naturally present
• Security- and Power-Aware Routing/Transmission
– Adapt routing by adjusting transmission range/power

6
 Presentation Outline

• Brief Overview of Techniques Implemented

• Update on Security Broker
• Security service composition
• Embedded IV Manager
• Application: “Waking Up Big Brother”

• Project Status, Success Criteria, Plans,

Schedule, Milestones, Technology Transfer

7
 Presentation Outline

• Brief Overview of Techniques Implemented

• Update on Security Broker
• Security service composition
• Embedded IV Manager
• Application: “Waking Up Big Brother”

• Project Status, Success Criteria, Plans,

Schedule, Milestones, Technology Transfer

8
 Lightweight Security Protocol (LiSP)

Motivation:
• Periodic key updates are necessary
• Frequent key exchange, retransmissions (due to unreliable media)
and acknowledgements consume significant power
Solution:
• Provide lightweight key update (to maximize sensor lifetime) by
exploiting information redundancy in key sequences
Summary Results:
• Implicit authentication for new keys, easy recovery of keys, no
retransmissions
• Resource consumption relatively low: less than 3 hash
computations even when more than 40% of the temporary keys are
compromised or lost.

9
 Fault Detection

Motivation:
• Faults compromise security: may be maliciously injected by an
attacker to probe the system and extract the secret key
• Faults should be detected to avoid transmission of erroneous
messages
Solution:
• Check-bit prediction developed for RC5, AES
• Detect faults to block output of erroneous results

Summary Results:
• All single bit failures detected
• Most of the multiple faults detected with the 4-bit parity and
Residue-15 codes – percentage undetected faults less than 1%

10
 Transmission Scheme Tradeoffs
Motivation:
• Radio communication is very energy-intensive
Annulus Am • If multi-hop forwarding is used, nodes close to
the base station can rapidly deplete their
... batteries; reaching directly to BS requires high
BS transmission power
• The network lifetime limited by the nodes with
maximum power consumption
...
Solution:
Capable of direct
transmission
Need forwarding
to reach BS
• Move hotspot from innermost annulus
• Probabilistic traffic balancing
– Forward packets with probability  f ( k )
– Transmit packets directly (high power) to the
BS with probability 
d (k )  1   f (k )
Summary:
• Approach prolongs sensor network lifetime
(power saving depends on size of network,
maximum range, density)

11
 Presentation Outline

• Brief Overview of Techniques Implemented

• Update on Security Broker
• Security service composition
• Embedded IV Manager
• Application: “Waking Up Big Brother”

• Project Status, Success Criteria, Plans,

Schedule, Milestones, Technology Transfer

12
 Security Broker

Motivation:
• Different applications require different security
services
• Different environments (external/internal)
require different levels of security provision
• Resource-limited devices cannot afford to
overprovision
• No one-size-fits-all solution exists

Objective: Maximize sensor lifetime by providing

applications “just enough” security protection

13
 Approach

• Pre-deploy security application comp

components at the link layer

messag
active message
• Runtime service composition

e
– aspects of security

packet
concerns (e.g., integrity, Radio Packet

confidentiality, replay
Service Library
attacks)
Security Broker
– levels of security provision
(e.g., encryption Cipher Library
algorithm, # rounds, block byte Radio byte
size)
– react adaptively
(external/internal RFM
bit

requirements)
14
 Packet Format – Security Encoding

Bytes 2 1 1 Block size/2 Block size/2 2

dest AM* length Data IV MAC CRC

Mandatory fields
for all services

Bits Optional fields based

on service composition

Security Composition ID
(SCID) “X1” and “X2”, is used to
– “C” = Confidentiality represent the strength of the
– “I” = Integrity cipher used.
– “S” = Semantic security
with implicit counter
– “R” = Replay protection
– “0000”, then no security
service is provided

15
 Energy Comparison
Systems Packet sizes Energy consumption
CISR=0000 14 bytes 229,600 nJ
CISR=1000 14 bytes 242,380 nJ (31.4%)

Broker CISR=0100 16 bytes 275,180 nJ (22.2%)

CISR=1100 16 bytes 287,960 nJ (18.6%)

CISR=1111 20 bytes 353,560 nJ

TinySec 20 bytes 353,560 nJ

TinyOS 16 bytes 262,400 nJ

• SenseToRfm application with 8 byte payload

• Picking a lower level of security can significantly prolong the
network lifetime
– 31.4% savings for Confidentiality only (CISR=1000)
– 22.2% savings for Integrity only (CISR=0100)
– 18.6% saving for Confidentiality and Integrity (CISR=1100)

16
 Embedded IV Manager

Part of Security Broker

Motivation:
• Semantic security and defense against replay attacks
often requires using an Initialization Vector (IV) with
every packet
• IVs consume a substantial amount of bandwidth (bits
transmitted)
• Most power is consumed during communication, thus
IVs increase power consumption significantly
Objective:
• Maximize sensor lifetime by providing applications
“embedded” (vs. explicit) semantic security protection

17
 How does it work?

• Setup IV once per session

• Embed IV in the encryption of checksum after setup
– No explicit IV is sent
– IV is calculated from the checksum at the receiver
– Receiver uses difference between its expected IV and
received IV to accept or reject packets
• To counter packet loss and out of order packets
– Allow outstanding IVs, but only within a predefined window
– Two consecutive IVs ahead of window indicate
synchronization loss and trigger resetting IV at the receiver
(to next expected IV)

18
 At the Sender

H M EK1,IV(M)

EK2(H | EK1,IV)

IV EK2(H | EK1,IV)IV
Encrypt with K3
C=EK3 (EK2(H | EK1,IV)IV)

H EK1,IV(M) C

19
 At the Receiver

IV can be calculated from checksum

H EK1,IV(M) C
Header Ciphertext Checksum
H EK1,IV(M) EK3 (EK2(H | EK1)IV)

Calculate Decrypt with K3

EK2(H | EK1 )  EK2(H | EK1)IV

IV This is IV used by sender!

20
 Results and Benefits

Energy vs Bit Error Ratio (Packet Retransmission)

9.E+10

8.E+10
Energy Consumption (nJ) .

7.E+10

6.E+10
Explicit IV
5.E+10 Window size = 2
Window size = 4
4.E+10 Window size = 8
Window size = 16
3.E+10

2.E+10

1.E+10

0.E+00
200 400 600 800 1000 1200 1400 1600 1800 2000 2200 2400 2600 2800 3000 3200

1/BER

• Trades transmission power with computation

• 23% energy reduction possible

21
 Demonstration

• We add security services to the “Waking Up Big

Brother” application
– Developed by J. Stankovic, T. Abdelzaher (Virginia) and B.
Krogh (CMU), et al
– Application is based on ad-hoc sensor network that tracks
intruders in a field and wakes up SOCOM sensor (“Big
Brother”)
– A sentry-based aggressive power management scheme is
used: only “sentry” motes are awake, other motes are in
sleep mode to preserve battery power
• Our contributions:
– Incorporate security services
– Show defense against various security attacks
– Show security - resource consumption tradeoffs
– Port application to TinyOS 1.1

22
Phase I

23
24
Phase I

25
 Presentation Outline

• Brief Overview of Techniques Implemented

• Update on Security Broker
• Coarse-grained services
• Fine-grained: embedded IV Manager
• Application: “Waking Up Big Brother”

• Project Status, Success Criteria, Plans,

Schedule, Milestones, Technology Transfer

26
 Project Status

• We are currently on target on milestones

proposed
– Initial version of Security Broker
– LiSP demonstrated
– Fault detection in encryption completed
– Integration of security services into “Waking Up
Big Brother” application started
• Simulation-level integration working
• Demonstration on motes with all middleware security
techniques is work in progress

27
 Goals and Success Criteria

• Goals
– Ensure appropriate security levels and prolong
sensor network lifetime
– Integrate security with performance, power, and
reliability

• Success criteria
– Software prototype (security services) integrated
and demonstrated with one application
– Security capabilities for various attack scenarios
and power saving demonstrated

28
 Selected Recent Publications
Taejoon Park and Kang G. Shin, ``LiSP: A Lightweight Security Protocol for
wireless sensor networks,'' ACM Transactions on Embedded Computer Systems (in press)

G. Bertoni, L. Breveglieri, I. Koren, P. Maistri and V. Piuri,

``Detecting and Locating Faults in VLSI Implementations of the Advanced
Encryption Standard,"  Proc. of the 2003 IEEE
International Symposium on Defect and Fault Tolerance in VLSI Systems,
pp. 105-113, November 2003.

Q. Xue, A. Ganz, "Runtime Security Composition for Sensor Networks

(SecureSense)", Vehicular Technology Conference, Orlando, FL, October
2003.
 
Q. Xue, A. Ganz, "Adaptive Mesh Routing in Mesh Wireless LANs",
Vehicular Technology Conference, Orlando, FL, October 2003.

G. Bertoni, L. Breveglieri, I. Koren, P. Maistri and V. Piuri,

``Concurrent Fault Detection in a Hardware Implementation of the RC5
Encryption Algorithm,"  Proc. of ASAP'03 - the Internl. Conference
on Application-Specific Systems, Architectures and Processors,
pp. 423-432, June 2003.

G. Bertoni, L. Breveglieri, I. Koren, P. Maistri and V. Piuri, 

``Error Analysis and Detection Procedures for a Hardware Implementation
of the Advanced Encryption Standard,"  IEEE Trans. on
Computers, Special Issue on Cryptographic Hardware and Embedded
Systems, pp. 492-505, April 2003.

29
 Project Plans

• Demonstrate security services in the “Waking

Up Big Brother” application
• Performance goals
– Provide “just enough” security to reduce power
consumption
– Up to 35% energy saving depending on security
attack, channel noise, and application
• How progress will be measured
– Energy security tradeoffs evaluated
– Energy reduction for various scenarios evaluated
– Software prototype of application with security
middleware (TinyOS 1.1, Mica 2) deployed
30
 Project Milestones

• Key 3 tasks remaining:

– Security Broker integrated with IV Manager
(Q3FY04)
– Integration with the LISP lightweight key exchange
(Q3FY04)
– Incorporate security services into the “Waking Up
Big Brother” application (Q4FY04)
• Demonstration event (Q4FY04)
– Security middleware software prototype
incorporated into the “Waking Up Big Brother”
application
– Resource consumption tradeoffs and security
services demonstrated

31
 Overall Project Schedule

• Q1FY03 Evaluation of Encryption Techniques

• Q4FY03 Incorporating fault-tolerance
• Q4FY03 Lightweight security protocol
• Q3FY04 Security Broker with other Integrated
Middleware Techniques
• Q3FY04 Software prototype
• Q4FY04 Experimentation & validation

32
 Technology Transfer

• CASA Engineering Research Center

– Collaborative multi-University effort led by UMass
ECE department
– Intelligent network of radars and sensors –
targeting severe weather prediction and tracking
– Longer term use of information includes: air traffic
controllers, civil defense
• Security aspect is critical

33
 Program Issues

• Quality of hardware platform

• Development tools

34
Thank you!

35
36
 How does it work?

• Temporal keys (TKs) and refresh interval sent

to sensors for encrypting/decrypting data
• TKs distributed well before their use
• Sensors buffer sequence and generate TKs
using a cryptographic one-way function TKi =
H(TKi+1)

37
 TK Management Steps at Sensors
buffer
• Receive a TK (way ahead
of its use)
• Verify authenticity

• Buffer TKk if correct

• Recover missing TK from

later TK with help of hash
function
• Rekey after half the refresh
interval to next TK

38
Impact of TK Loss

39
 Summary of LiSP

• Resource consumption relatively low: less

than 3 hash computations even when more
than 40% of the TKs are compromised or lost.
– No retransmissions or acknowledgements
– Implicit authentication for new keys
– Easy recovery of lost keys
– Tolerance to clock skews allows us to refresh keys
on a slightly non-periodic basis

40
 Transmission Cost/Tradeoffs

• Possible approaches to deliver information:

– Reach directly to BS if in range using
• High-power consumed per transmission
Transmission power (Pt) law:

– a,b are constants; α is related to attenuation; r is range

– Power is increasing exponentially with range

– Multi-hop forwarding
• Total transmission energy declines (due to exponentially
lower power cost for shorter transmissions)
• Channel congestion decreases (due to shorter range)
• But, nodes in the inner annuli consume battery fast!

41
 Devised Transmission Schemes

• P-hybrid – probabilistic traffic

balancing (assume within
Annulus Am
range)
...
– Move the hot spot from the inner-
BS
most Annulus
– Forward packets with probability  f ( k )
... – Transmit packets directly to the BS
Capable of direct
transmission
Need forwarding
to reach BS
with probability:
d (k )  1   f (k )
• T-hybrid – combine P-hybrid
with threshold
– Transmit first to cells within range
– Use P-hybrid within range
• Evaluation is ongoing work
42
 Fault Detection for RC5

• We have focused on four detection techniques:

Type of EDC # of redundant bits Redundancy
Word parity 1 3%
Byte parity 4 12.5%
Residue 3 2 6.25%
Residue 15 4 12.5%

• Check-bit prediction schemes were developed

for all four techniques
• All single bit failures were detected by all four
schemes

43
 Multiple Fault Coverage

• Summary: The 4-bit parity and Residue-15 codes achieve the highest
coverage of multiple faulty bits – percentage undetected faults less than
1% in most cases

44
45