security tradeoffs in nest dec 16, 2003

45
1 Security Tradeoffs in NEST Dec 16, 2003 C. M. Krishna, I. Koren, A. Ganz, C. Andras Moritz (presenter) University of Massachusetts, Amherst K. G. Shin University of Michigan Y.-H. Lee Arizona State University

Upload: dexter

Post on 20-Jan-2016

35 views

Category:

Documents


0 download

DESCRIPTION

Security Tradeoffs in NEST Dec 16, 2003. C. M. Krishna, I. Koren, A. Ganz, C. Andras Moritz (presenter) University of Massachusetts, Amherst K. G. Shin University of Michigan Y.-H. Lee Arizona State University. Administrative. Project Title: Security Tradeoffs in NEST - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Security Tradeoffs  in NEST Dec 16, 2003

1

Security Tradeoffs in NESTDec 16, 2003

C. M. Krishna, I. Koren, A. Ganz,

C. Andras Moritz (presenter)University of Massachusetts, Amherst

K. G. Shin University of Michigan

Y.-H. Lee Arizona State University

Page 2: Security Tradeoffs  in NEST Dec 16, 2003

2

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): [email protected]

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

Page 3: Security Tradeoffs  in NEST Dec 16, 2003

3

Subcontractors and Collaborators

• Subcontractors– University of Michigan– Arizona State University

• Collaborators– University of Virginia– BBN– UC Berkeley– SRI

Page 4: Security Tradeoffs  in NEST Dec 16, 2003

4

Problem and ChallengeProblem and ChallengeProblem and ChallengeProblem and Challenge

ImpactImpactImpactImpact

New IdeasNew IdeasNew IdeasNew Ideas

ScheduleScheduleScheduleSchedule

• Adapting security level of each task to application requirements and system constraints.

• Security broker to select the appropriate security protocol.

• Fault-tolerance and performance integrated with security

Security Tradeoffs in NESTUniversity of Massachusetts; University of Michigan; Arizona State University

•Q4FY03 • Encryption mechanisms• Incorporating fault-tolerance• Intrusion detection• Secured wireless protocol

•Q2FY04 - Security Broker •Q2FY04 - IV Manager•Q3FY04 - Software prototype•Q4FY04 - Experimentation & validation

Ensures appropriate levels of security for application needs.

Integrates security with performance, reliability, power requirements and constraints.

Enables dynamic adjustments as needs and resource availability change.

PI NameAffiliation

Mid

dle

war

e

SystemConstraints

SecurityRequirements

ApplicationNeeds

TinyOSTinyOS

SERVICES • Security Broker• Power Management• Failure Handling• Intrusion Detection

SERVICES • Security Broker• Power Management• Failure Handling• Intrusion Detection

Other Services• Allocation• Scheduling• Routing• ….

Other Services• Allocation• Scheduling• Routing• ….

Page 5: Security Tradeoffs  in NEST Dec 16, 2003

5

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

Page 6: Security Tradeoffs  in NEST Dec 16, 2003

6

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

Page 7: Security Tradeoffs  in NEST Dec 16, 2003

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

Page 8: Security Tradeoffs  in NEST Dec 16, 2003

8

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

Page 9: Security Tradeoffs  in NEST Dec 16, 2003

9

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.

Page 10: Security Tradeoffs  in NEST Dec 16, 2003

10

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%

Page 11: Security Tradeoffs  in NEST Dec 16, 2003

11

Transmission Scheme Tradeoffs

Motivation:• Radio communication is very energy-intensive• If multi-hop forwarding is used, nodes close to

the base station can rapidly deplete their batteries; reaching directly to BS requires high transmission power

• The network lifetime limited by the nodes with maximum power consumption

Solution:• Move hotspot from innermost annulus• Probabilistic traffic balancing

– Forward packets with probability – Transmit packets directly (high power) to the

BS with probabilitySummary:• Approach prolongs sensor network lifetime

(power saving depends on size of network, maximum range, density)

BS

Annulus Am

Need forwardingto reach BS

Capable of directtransmission

...

...

( )f k

( ) ( )1d k f k

Page 12: Security Tradeoffs  in NEST Dec 16, 2003

12

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

Page 13: Security Tradeoffs  in NEST Dec 16, 2003

13

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

Page 14: Security Tradeoffs  in NEST Dec 16, 2003

14

Approach

• Pre-deploy security components at the link layer

RFM

Radio byteb

itb

yte

Radio Packet

pa

ck

et

active messageactive message

application comp

me

ss

ag

e

Security Broker

Cipher Library

Service Library

• Runtime service composition – aspects of security

concerns (e.g., integrity, confidentiality, replay attacks)

– levels of security provision (e.g., encryption algorithm, # rounds, block size)

– react adaptively (external/internal requirements)

Page 15: Security Tradeoffs  in NEST Dec 16, 2003

15

Packet Format – Security Encoding

Security Composition ID (SCID)– “C” = Confidentiality – “I” = Integrity– “S” = Semantic security

with implicit counter – “R” = Replay protection– “0000”, then no security

service is provided

dest AM* IVlength Data MAC CRC

Bytes 2 11 Block size/2 Block size/2 2

“X1” and “X2”, is used to represent the strength of the cipher used.

Mandatory fields for all services

Optional fields based on service composition

Bits

Page 16: Security Tradeoffs  in NEST Dec 16, 2003

16

Energy Comparison

• 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)

262,400 nJ16 bytesTinyOS

353,560 nJ20 bytesTinySec

353,560 nJ20 bytesCISR=1111

287,960 nJ (18.6%)16 bytesCISR=1100

275,180 nJ (22.2%)16 bytesCISR=0100

242,380 nJ (31.4%) 14 bytesCISR=1000

229,600 nJ14 bytesCISR=0000

Broker

Energy consumptionPacket sizes Systems

Page 17: Security Tradeoffs  in NEST Dec 16, 2003

17

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

Page 18: Security Tradeoffs  in NEST Dec 16, 2003

18

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)

Page 19: Security Tradeoffs  in NEST Dec 16, 2003

19

At the Sender

MMHH EK1,IV(M)EK1,IV(M)

EK2(H | EK1,IV)

IV EK2(H | EK1,IV)IV

Encrypt with K3

C=EK3 (EK2(H | EK1,IV)IV)

EK1,IV(M)EK1,IV(M)HH CC

Page 20: Security Tradeoffs  in NEST Dec 16, 2003

20

At the Receiver

Checksum EK3 (EK2(H | EK1)IV)

CiphertextEK1,IV(M)

HeaderH

EK1,IV(M)EK1,IV(M)HH CC

Calculate

EK2(H | EK1 )

Decrypt with K3

EK2(H | EK1)IV

IV This is IV used by sender!

IV can be calculated from checksum

Page 21: Security Tradeoffs  in NEST Dec 16, 2003

21

Results and Benefits

• Trades transmission power with computation• 23% energy reduction possible

Energy vs Bit Error Ratio (Packet Retransmission)

0.E+00

1.E+10

2.E+10

3.E+10

4.E+10

5.E+10

6.E+10

7.E+10

8.E+10

9.E+10

200 400 600 800 1000 1200 1400 1600 1800 2000 2200 2400 2600 2800 3000 3200

1/BER

En

erg

y C

on

su

mp

tio

n (

nJ)

.

Explicit IV

Window size = 2

Window size = 4

Window size = 8

Window size = 16

Page 22: Security Tradeoffs  in NEST Dec 16, 2003

22

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

Page 23: Security Tradeoffs  in NEST Dec 16, 2003

23

Phase I

Page 24: Security Tradeoffs  in NEST Dec 16, 2003

24

Page 25: Security Tradeoffs  in NEST Dec 16, 2003

25

Phase I

Page 26: Security Tradeoffs  in NEST Dec 16, 2003

26

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

Page 27: Security Tradeoffs  in NEST Dec 16, 2003

27

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

Page 28: Security Tradeoffs  in NEST Dec 16, 2003

28

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

Page 29: Security Tradeoffs  in NEST Dec 16, 2003

29

Selected Recent Publications

Taejoon Park and Kang G. Shin, ``LiSP: A Lightweight Security Protocol forwireless 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 AdvancedEncryption Standard,"  Proc. of the 2003 IEEEInternational 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, October2003.  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 RC5Encryption Algorithm,"  Proc. of ASAP'03 - the Internl. Conferenceon 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 Implementationof the Advanced Encryption Standard,"  IEEE Trans. on Computers, Special Issue on Cryptographic Hardware and Embedded Systems, pp. 492-505, April 2003.

Page 30: Security Tradeoffs  in NEST Dec 16, 2003

30

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

Page 31: Security Tradeoffs  in NEST Dec 16, 2003

31

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

Page 32: Security Tradeoffs  in NEST Dec 16, 2003

32

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

Page 33: Security Tradeoffs  in NEST Dec 16, 2003

33

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

Page 34: Security Tradeoffs  in NEST Dec 16, 2003

34

Program Issues

• Quality of hardware platform• Development tools

Page 35: Security Tradeoffs  in NEST Dec 16, 2003

35

Thank you!

Page 36: Security Tradeoffs  in NEST Dec 16, 2003

36

Page 37: Security Tradeoffs  in NEST Dec 16, 2003

37

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)

Page 38: Security Tradeoffs  in NEST Dec 16, 2003

38

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

Page 39: Security Tradeoffs  in NEST Dec 16, 2003

39

Impact of TK Loss

Page 40: Security Tradeoffs  in NEST Dec 16, 2003

40

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

Page 41: Security Tradeoffs  in NEST Dec 16, 2003

41

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!

Page 42: Security Tradeoffs  in NEST Dec 16, 2003

42

Devised Transmission Schemes

• P-hybrid – probabilistic traffic balancing (assume within range)– Move the hot spot from the inner-

most Annulus– Forward packets with probability – Transmit packets directly to the

BS with probability:

• T-hybrid – combine P-hybrid with threshold – Transmit first to cells within range – Use P-hybrid within range

• Evaluation is ongoing work

( )f k

( ) ( )1d k f k

BS

Annulus Am

Need forwardingto reach BS

Capable of directtransmission

...

...

Page 43: Security Tradeoffs  in NEST Dec 16, 2003

43

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

Page 44: Security Tradeoffs  in NEST Dec 16, 2003

44

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

Page 45: Security Tradeoffs  in NEST Dec 16, 2003

45