Roadmap

1
Roadmap

• Brief introduction
• ZigBee current industry standard
• Detecting malicious nodes
• Detecting node replication attacks
• Secure data aggregation
• Software-based attestation

2
Secure Data Aggregation

• Goal detect malicious data aggregation with
  probability 1
• Secure Hierarchical In-network Data Aggregation
  for Sensor Networks, with Haowen Chan and Dawn
  Song published at CCS 2006

3
Data Query on a Sensor Network
Q
Sensor readings
(( ))
0
2
0
3
1
4
2
3
4
Responding to a Data Query
Q
(( ))
0
What is the sum of all the sensor readings?
2
0
3
1
4
2
3
5
Metric Edge Congestion

• Amount of traffic on most heavily loaded link
• Nodes adjacent to heaviest loaded links consume
  their energy fastest
• Naïve data forwarding yields O(n) edge congestion

6
Data Aggregation

15
Q
(( ))
0
9
What is the sum of all the sensor readings?

6
2
0
Answer
3
9

edge congestion
1

4
4
2
3
7
Attacker Model

• Unsecured deployment area
• Sensor nodes not tamper-resistant
• Adversary may undetectably take control of sensor
  nodes or base station
• Adversary goal
• Cause querier to accept a falsified query result
• Our goal
• Detect if a query result was falsified

8
Correct Data Aggregation
Q
15
(( ))
9
0
6
0
9
2
0
3
4
4
2
3
1
4
2
3
9
Sensor Reading Falsification
Q
21
(( ))
15
0
6
0
15
2
0
Malicious node reports false sensor
reading (within legal bounds)
3
4
10
2
3
1
4
2
3
10
Sensor Reading Falsification

• General aggregation problem
• Assume no application-specific information
• Attackers data indistinguishable from true data
• No defense possible against sensor reading
  falsification
• Attackers ability limited by how many nodes
  compromised

11
Aggregation Result Falsification
Q
106
(( ))
100
0
6
0
100
2
0
3
4
4
2
3
1
4
2
3
12
Aggregation Result Falsification

• Malicious node fabricates its aggregation result
• Single malicious node may cause unbounded
  deviation in query result
• Secure aggregation problem
• Can we restrict the attackers ability to falsify
  aggregation results?
• Tightest possible restriction without application
  knowledge
• Attacker can only perform sensor reading
  falsification attacks or equivalent

13
Prior Related Work

• Either probabilistic detection or only for
  special cases
• Single malicious node
• L. Hu and D. Evans 2003
• P. Jadia and A. Mathuria 2004
• Flat aggregator topology
• B. Przydatek, A. Perrig, D. Song 2003
• W. Du, J. Deng, Y. Han, P.K. Varshney 2003
• Probabilistic Detection
• B. Przydatek, A. Perrig, D. Song 2003
• Y. Yang, X. Wang, S. Zhu, G. Cao 2006

14
Our Algorithm

• General hierarchical (tree-based) aggregation
  topologies
• Multiple (unbounded) number of compromised nodes
• Provably secure
• Achieves tightest possible bound on adversary
  ability to change aggregation result
• Low communication overhead
• O(log2(n)) edge-congestion

15
Preventing SUM Result Deflation

• Consider only the SUM aggregate
• Straightforward reductions from COUNT, AVG,
  MEDIAN to SUM
• Adversary only wishes to reduce aggregate result
• Use COMPLEMENT to protect against increase
• Sensor readings are nonnegative in 0, m
• Let S be sum of all sensor readings
• We detect adversary if aggregate S lt S
• Adversary gains no additional benefit from
  aggregation result falsification vs. sensor
  reading falsification

16
Generating Commitments

• Aggregate-commit-prove approach proposed in SIA
  by Przydatek et al. Sensys03
• Require nodes to cryptographically commit to a
  single version of aggregation process
• Any aggregation result falsification results in
  an inconsistency in a fixed position in
  commitment structure
• If that position is probed, inconsistency will be
  discovered

17
Commitment Tree (Naive)

• Aggregation Tree

• Commitment Tree

F
E
D
C
B
A
MAB h(MA MB ) va vb
MABCD h(MAB MD MC )


18
Probing Example

• To probe MC
• Request MAB MD ME MF
• Recompute MABCD MABCDEF

19
Distributed Probing

• Most prior work relies on the querier to issue
  probes to verify result integrity
• Idea distribute probing process to sensor nodes

20
Verifying a Commitment Tree

• Querier disseminates commitment tree root MR
  using authenticated broadcast
• E.g., TESLA by Perrig et al. IEEE SP01
• Node A verifies its contribution
• Node A receives commitment tree root MR
• Node A requests all siblings of commitment tree
  vertices between MA and root
• Verify that inputs to each aggregation step are
  non-negative
• Verify that correct MR can be recomputed

21
Aggregating Verification Results

• Each node shares a secret key with querier
• Node As OK bitphrase for query k
• MACKA (Query k verified OK by node A)
• OK bitphrases are aggregated using XOR
• Querier verifies that received aggregate
  bitphrase is XOR of all bitphrases
• If any node does not respond with OK, this test
  will fail aggregation result rejected

22
Aggregating with XOR
1000
1111
1010
0010
0110
0101
0011
23
Correctness

• Lemma If two legitimate nodes A and B both pass
  their verifications, then SUM aggregate has value
  at least vA vB

Observation Intermediate sums are non-decreasing.
24
Correctness
25
Correctness

• Corollary If all legitimate nodes pass their
  verifications, then final aggregation result is
  at least
• Lower bound adversary cannot report result less
  than sum of legitimate sensor readings
• Nodes verify their contribution ? but aggregator
  can add additional sources
• Upper bound aggregate complement maxvi
• Check that SUM COMPLEMENT nmax

?
S
v

i
l
i
t
i
e
g
26
Naive Commitment Tree

• Aggregation Tree

• Commitment Tree

F
E
D
C
B
A
Topology of commitment tree is identical to
aggregation tree (with addition of pendant
vertices to all internal nodes)
27
Balancing the Commitment Tree

• Aggregation Tree unbalanced
• Naïve Commitment Tree unbalanced
• Long paths in commitment tree
• High communication overhead
• Idea Instead of one commitment tree, keep a
  forest of O(log n) complete commitment trees
• Construct this using delayed aggregation

28
Delayed Aggregation

• Only perform aggregation on subtrees of equal
  height

D
C
B
A
29
Delayed Aggregation

• All trees in commitment forest are complete and
  have distinct heights
• Tallest tree has height at most log n
• At most log n trees
• Each sensor node receives (and transmits)
• O(log n) commitment subtree root values

30
Congestion Bound

• Commitment tree ! overlay network of the
  aggregation tree
• Each commitment tree vertex resides at the sensor
  node that created it
• For A to self-probe,
• Send all off-path vertices
• to its leaf vertex MA
• O( log n ) congestion
• at leaf edge of MA

MA
31
Congestion Bound

• In aggregation tree, each sensor node reports
  
• roots of O( log n ) subtrees to its parent
• Responsible for receiving traffic for O( log n )
  parent edges incident to these
  vertices in the commitment forest
• O( log n ) edge-congestion in commitment forest
  and O( log2 n ) edge congestion in aggregation
  tree

32
Summary

• Secure distributed hierarchical aggregation
• Properties
• Malicious nodes can at best falsify their own
  sensor reading
• Cheating aggregator node is caught with
  probability 1

33
Roadmap

• Brief introduction
• ZigBee current industry standard
• Detecting malicious nodes
• Detecting node replication attacks
• Secure data aggregation
• Software-based attestation

34
Software-Based Attestation

• Goal provide attestation guarantees on legacy
  hardware, without trusted TPM chip
• Projects
• SWATT Software-based attestation, with Arvind
  Seshadri, Leendert van Doorn, and Pradeep Khosla
  IEEE SP 2004
• SCUBA Secure Code Update By Attestation in
  Sensor Networks, with Arvind Seshadri, Mark Luk,
  Leendert van Doorn, and Pradeep Khosla ACM WiSe
  2006

35
SWATT Overview

• External, trusted verifier knows expected memory
  content of device
• Verifier sends challenge to untrusted device
• Assumption attacker has full control over
  devices memory before check
• Device returns memory checksum, assures verifier
  of memory correctness

External Verifier
Embedded device
Checksum function
Device memory
Expected device memory contents
36
Assumptions Attacker Model

• Assumptions on verifier
• Knows hardware configuration of device
• Assumptions on device (untrusted host)
• Hardware and firmware is trustworthy
• No proxy attacks
• Attacker controls devices software and OS before
  verification

37
Checksum Function Design

• Approach 1 Verifier asks device to compute a
  cryptographic hash function over memory
• V ? D Checksum request
• D ? V SHA-1( Memory )
• Attack malicious code pre-computes and replays
  correct hash value

Checksum Code
Malicious Code
0 .. 0
Code
Unused memory
38
Checksum Function Design

• Approach 2 Verifier picks a random challenge,
  device computes Message Authentication Code (MAC)
  using challenge as a key
• V ? D Checksum request, random K
• D ? V HMAC-SHA-1( K, Memory )
• Attack Malicious code computes correct checksum
  over expected memory content

Checksum Code
Malicious Code
0 .. 0
Code
Unused memory
39
Checksum Function Design

• Observation need externally detectable property
  that reveals tampering of checksum computation
• Approach
• Use time as externally detectable property,
  create checksum that slows down if tampering
  occurs
• Compute checksum in pseudo-random order
• Attacker needs to verify each memory access ?
  slowdown

Checksum Code
Malicious Code
0 .. 0
Code
Unused memory
40
SWATT Checksum Requirements

• Optimal implementation code cannot be optimized
• Denali project _at_ HP labs provides proof of
  optimal implementation
• GNU superopt
• Open challenge to prove optimality of SWATT
  checksum
• Non-parallelizable checksum
• Non-predictable checksum
• Given a change, checksum cannot be adjusted

41
SWATT Advantage

• SWATT time advantage running time of fastest
  attack code running time of SWATT checksum code
• Verification procedure loop has 16 assembly
  instructions and takes 23 cycles
• Checks use if statements
• Translates to compare branch in assembly,
  requires 3 cycles
• Insertion of single if statement increases loop
  execution time
• 13 increase per iteration in our implementation

42
SWATT Assembler Code
Generate ith member of random sequence using
RC4 zh 2 ldi zh, 0x02 r15 (x) ld r15,
x yl yl r15 add yl, r15 zl y ld zl,
y y r15 st y, r15 x r16 st x, r16 zl
zl r15 add zl, r15 zh z ld zh,
z Generate 16-bit memory address zl r6 mov
zl, r6 Load byte from memory and compute
transformation r0 z lpm r0, z r0 r0 xor
r13 xor r0, r13 r0 r0 r4 add r0,
r4 Incorporate output of hash into checksum r7
r7 r0 add r7, r0 r7 r7 ltlt 1 lsl r7 r7
r7 carry_bit adc r7, r5 r4 zh mov r4, zh
43
Results
44
SWATT Extension

• Drawback checksum computed over entire device
  memory
• Does not scale to large memory sizes
• Memory may contain secrets
• Memory may contain dynamic data
• Solution design checksum function that can
  check memory areas of arbitrary size
• Memory area being checked includes checksum
  function
• Challenge many new attacks possible!

45
Attack on Partial Memory Verification

• Checksum computed over small part of memory
• Memory copy attack attacker computes checksum
  over correct copy of memory

Checksum Code
Malicious Code
0 .. 0
Code
Unused memory
46
ICE Indisputable Code Execution

• Add chksum function execution state to checksum
• Include program counter (PC) and data pointer
• In memory copy attack, one or both will differ
  from original value
• Attempts to forge PC and/or data pointer
  increases attackers execution time

Checksum Code
Malicious Code
0 .. 0
Code
Unused memory
47
ICE Assembler Code
Seed from verifier
Generate random number using T-Function mov r15,
0x130 mov r15, 0x138 bis 0x5, 0x13A add
0x13A, r15 Load byte from memory add r0, r6 xor
_at_r13, r6 Incorporate byte into checksum add r14,
r6 xor r5, r6 add r15, r6 xor r13, r6 add r4,
r6 rla r4 adc r4
T-Func
Address Generation
Memory Read
Compute Checksum
48
ICE Verification Function

• Implemented as self-checksumming code
• Computes checksum over its own instructions
• Set up untampered execution environment
• CPU state for atomic execution
• E.g., turn off interrupts
• Compute checksum
• Using memory contentsand CPU state
• Checksum verifies integrityand correct set-up
  ofexecution environment

Verification Function
Target Code
49
ICE Protocol
Wireless link
Node
Base station
Verf. Func.

• Successful verification if t2 t1 lt
  expected time and cksum exp. cksum

Target Code
50
ICE Results
51
ICE Summary

• Given target code T, verifier obtains property
  that sensor node S correctly executes T,
  untampered by any other (malicious) code
  potentially present on S
• By incorporating node ID into checksum
  computation, we can authenticate response

52
Key Establishment

• How to establish a shared secret?
• Attacker may know entire memory contents of a
  newly shipped node
• After a node has been compromised, attacker may
  have altered authentic public keys or knows
  secret keys
• Without authentication Diffie-Hellman protocol is
  vulnerable to man-in-the-middle attack
• A ? B ga mod p
• B ? A gb mod p

53
Problem Formulation

• Given nodes in a sensor network, how can any pair
  of nodes establish a shared secret without any
  prior authentic or secret information?
• In theory, this is impossible because of active
  MitM attack
• Assumptions
• Attacker cannot compute faster than sensor node
• Each node has a unique, public, unchangeable
  identity stored at a fixed memory address
• Secure source of random numbers

54
ICE Key Establishment

• Intuition leverage ICE to compute checksum
  faster than any other node, and use that checksum
  as a short-lived shared secret!
• Challenge how to use short-lived shared secret
  to bootstrap long-lived secret?
• Authenticate Diffie-Hellman public key

55
First Attempt
A
B

• Pick random a Pick random b
• Compute ga mod p Compute gb mod p
• t0 ga mod p
• ga mod p challenge
• Compute cksum c
• t1 gb mod p, MAC(c, gb mod p)

56
Second Attempt
A
B

• Pick random a
• Compute ga mod p
• t0 ga mod p
• ga mod p challenge
• Compute cksum c
• Pick random b
• Compute gb mod p
• t1 gb mod p, MAC(c, gb mod p)

57
Guy Fawkes
A
B

• Goal A and B can authenticate each others
  messages
• Pick random v2 Pick random w2
• v1 H(v2), v0 H(v1) w1H(w2), w0H(w1)
• one-way chain v0 ? v1 ? v2 w0 ? w1 ? w2
• Assume A knows authentic w0 B knows authentic v0
  
• v1 , Ma , MAC( v2, Ma )
• w1 , Mb , MAC( w2, Mb )
• v2
• w2

58
ICE Key Establishment
A
B

• Pick random a, ga ga mod p
• Compute ga H(ga), ga H(ga), ga ? ga ?
  ga
• t0 ga
• ga challenge
• Compute cksum c
• w0 ? w1 ? w2
• t1 w0 MAC( c, w0 )
• random b, gb mod p
• ga
• w1, gb mod p, MAC(w2 , gb mod p)
• ga
• w2

59
Summary ICE Key Re-Establishment

• Protocol can prevent man-in-the-middle attacks
  without authentic information or shared secret
• Attacker can know entire memory content of both
  parties before protocol runs
• Forces attacker to introduce more powerful node
  into network, prevents remote attacks
• Future work relax strong assumption that
  attacker cannot compute faster

60
Conclusions

• Sensor networks provide opportunity to get
  security right before wide-spread deployment
• No need for disastrous security flaw
• Most applications need security
• Even seemingly benign sensor readings can reveal
  surprisingly sensitive information
• Privacy needs more research attention
• Existing industry standard assumes zero
  compromised nodes! No attempt yet made to detect
  and tolerate compromised nodes!