Transcript Wireless Sensor Network Security: The State of the Art

Wireless Sensor
Network Security:
The State of the Art
ASCI Springschool on Wireless
Sensor Networks
Yee Wei Law
The University of Melbourne
Prelude
 In the beginning, security objective for
civilian applications is unclear
 But communication with the industry
confirms our ‘suspicion’ about the
security requirements
 Endless challenges, every component of
WSNs has its corresponding security
issues
2
Roadmap
 Primer to cryptography and
WSNs
Information Assurance
Protection
Detection
Reaction
 Secure data aggregation
 Key management
 Other areas:
 secure remote reprogramming
 secure localization
 energy-efficient jamming attacks
3
Part Zero
Primer to cryptography and WSNs
Introduction to security
 Security threats: either somebody wants to steal
something from you or sabotage you
Information
security
Operation
security
Information assurance
 Information assurance (IA) is a set of measures that
protect and defend information and information
systems by ensuring their availability, integrity,
authentication, confidentiality, and non-repudiation.
These measures include providing for restoration of
information systems by incorporating protection,
detection, and re-action capabilities.
5
Primitives
 Security objectives:
 Confidentiality
 Integrity
 Authentication
 Non-repudiation
 Encryption / decryption
 Symmetric-key: E(K, M) / D(K, M)
 Asymmetric-key: E(PK, M) / D(SK, M)
 Signature / verification
 Symmetric-key: message authentication code (MAC), denoted
MAC(K, M)
 Asymmetric-key: digital signature, denoted
Notation:
Sign(SK, M), Ver(PK, M)
Public key = PK 6
Private key = SK
Common usage
Diff keys for encryption
and authentication
 E(K1, M) || MAC(K2, E(K1, M))
Confidentiality
Integrity,
authentication
 E(K1, M) || Sign(SK, h(E(K1, M)))
Confidentiality
Signing on hash
is more efficient
Integrity,
authentication,
non-repudiation
7
Birthday threshold
23 people (q)
birthdays (n)
 Collision probability C(N,q)
q (q  1)
2N
q (q  1)
If 1  q  2 N , 0.3
 C ( N , q)
2N
1  e  q ( q 1)/(2 N )  C ( N , q ) 
 Birthday attack on CBC-MAC [Bellare et al. 00]
uf-cma
AdvCBC
(q, O(lmq log q))  0.3
m
-F
number of queries
running time
(q  1)(q  2)
l /2

birthday
threshold

q

O
(2
)
l
2
8
Security notions (PKC)
 Semantic security = indistinguishability
Ciphertext doesn’t reveal anything about the plaintext
except the length
 Non-malleability
New ciphertexts cannot be created based on known
ciphertexts
 Satisfies a security notion, if an attacker loses to a
‘game’, e.g., the chosen plaintext attack (CPA) ‘game’
9
Challenges in WSNs
Constraints
Implications
Sensor node hardware,
resource constraints
Algos must be energy- and
storage-efficient
Nodes operate unattended
Adversary can compromise any
node
Nodes not tamper-resistant
Adversary can compromise any
node’s keys
No fixed infrastructure
Cannot assume any specialfunction node in vicinity
No pre-config’ed topology
Nodes don’t know neighbours in
advance
Communicate in an open
medium
Communications are worldreadable and world-writeable by
default
10
Security design principles
 Favour computation over communication
 Communication 1000 times more energy-consuming
than computation
 Minimal public-key crypto
 Tate pairing costs 5s (54mJ) on a Tmote Sky
(fastest recorded by [Szczechowiak et al. 08])
 Favour resilience (tolerance) over absolute
security
 Strength in number
11
Part One
Secure data aggregation
Data aggregation
aggregate
aggregate
aggregate
Purposes:
(1) Save bandwidth (limited data rate) Reason why we put a processor on
every node in the first place 13
(2) Save energy (limited energy)
Phase 1: Query
dissemination
Sample query:
SELECT AVERAGE(temperature) FROM sensors
14
WHERE floor = 6
EPOCH DURATION 30s
Phase 2: Data aggregation
aggregate
aggregate
aggregate
Types of aggregation:
(1) basic aggregation, (2) data compression, (3) parameter estimation
15
Phase 3: Result
verification (optional)
“Did you really
report this?”
“Did you really
report this?”
“Did you really
report this?”
“Did you really
report this?”
“Did you really
report this?”
“Did you
really report
this?”
16
Security goals of data
So the average is
aggregation
251.5… Oh wait a
minute
 Robustness: Byzantine
corruption of data would
not make aggregation
result totally
meaningless
 Confidentiality: To
ensure that other than
the sink and the sources,
no intermediate node
should have knowledge
of the raw data or the
aggregation result
perform averaging
1000
3
1
2
What the
hell am I
forwarding?
sink
What the
hell am I
aggregatin
g?
sources
17
Securing data aggregation:
multipronged defence
4
1
2
3
18
Resilient aggregation
 Objective: To bound the effect of data
corruption
 Corruption can be arbitrary – Byzantine
 By convention, we denote the number of
corruptions as k
 Methods:
 Robust statistics (1-hop networks)
 RANBAR (1-hop networks)
 Quantiles aggregation (multi-hop networks)
19
Robust statistics
Say an aggregation function is actually an estimator
Say we are estimating a parameter Θ and there are k rouge nodes
An aggregation function is (k,)-resilient if
ˆ , k )    rms(
ˆ)
rms*(
That is, the RMS error as a result of k-corruption, must be bounded
by a constant factor of the original RMS error
We win if we can limit 
The attacker wins if he manages to unbound 
20
Examples of (k,)-resilient
aggregation functions
y
y=y+
AVG
AVG
Non-resilient, example: Average
x1
Resilient, examples
x2
x3
x4
x2
x3
Resilience 
Aggregation function
Sample
median
distribution
x1
rms(y)> rms(y)
wrt
5%-trimmed average wrt
distribution
Gaussian
Gaussian
x4+4
Breakdown point ε*
 1  2 (k / n)2 , if k  n
0.5
 1 6.278k / n , if k < 0.05n
0.05
[l, u]-truncated average wrt Gaussian
distribution
1  (u  l ) /   k / n
Not applicable
Count wrt Bernoulli distribution with
parameter p
1  k 2 / [np(1  p)]
Not applicable
21
RANBAR
 Based on RANdom SAmple Consensus, which
originates in computer vision (hence the name
RANBAR = RANsac-Based AggRegation
[Buttyán et al. 06])
 Step1: Use as few samples as possible to
determine a preliminary model
 Step 2: Use the preliminary model to identify
samples that are consistent with the model
 Step 3: Refine the model with all the samples
that are found to be consistent
22
Quantiles aggregation
(extending resilient
aggregation to multihop)
6
4
Median
Median
2
2
2
Median
Median
1
10
3
4
Median
16
1
2
3
4
16
Actual median = 3
This approach suggests that instead
of taking a median every hop on the
way, we should compress the data
judiciously at each hop
23
Quantiles aggregation
count
tree nodes are numbered
Rules for deriving a q-digest:
Rule (A): count(node) + count(parent) + count(siblings) ≥ n/k + 1
Rule (B): count(node)  n/k
q-digest in this example: {<8,2>,<9,2>,<1,1>}
24
Quantiles aggregation
count
tree nodes are numbered
Derived median = data value represented by node 9 = 3.5
Actual median = 3
25
Resilient aggregation
guidelines
1-hop
Two approaches actually:
multihop
(1) estimate
by minimizing
effects of outliers
(2) detect outliers and
estimate without outliers
Data
distribution
known
Robust
statistics,
RANBAR
Quantiles
aggregation
Data
distribution
unknown
Robust
statistics
Quantiles
aggregation
26
Progress so far…
4
1
2
3
27
malicious
Voting
“is mean = 61.4 reasonable?”
malicious
3
300
2
1
malicious
1
Alright, 61.4
is not
reasonable!
No
Yes
No
Resource-intensive, only good for
mission-critical, small-scale networks
No
No
28
Progress so far…
4
1
2
3
29
Result verification
 The single-aggregator case
 The multi-aggregator case
 Chan et al.’s hierarchical in-network
aggregation
 Yang et al.’s SDAP
30
Interactive proof algo

By [Przydatek et al. 2003], algo for proving probabilistically a
given figure is indeed the median of the samples
Example for the sake of intuition:

1
Prover must have the samples sorted first
1
2
3
4
5
6
2
Prover tells the verifier median is 3.5 and the no. of samples is 6
3
Verifier asks for the 3rd sample, prover tells the 3rd sample is 3 <
3.5, verifier is happy but still suspicious
4
Verifier asks for the 4th sample, prover tells the 4th sample is 4 >
3.5, verifier is happy but still suspicious
Verifier asks for the 1st and 6th sample, prover tells 1st is 1 < 3.5
and 6th is 6 > 3.5, verifier says: “Alright, I’ve sampled enough,
median should be 3.5 at high probability”. Relies on the trustworthiness of the31
5
samples, but how do we make sure?
Result verification – single
aggregator
hi,j=h(hi+1,2j||h i+1,2j+1)
Sink S
q || A || f(x1,x2,...,xn ) || n || h A || MACAS
h1,0
A
q || ID(1) || x1 || MAC1S || MAC1A
(a)
h0,0
1
2
...
n
x1
x2
...
xn
h1,1
h2,0
h2,1
h2,2
h2,3
x1
x2
x3
x4
(b)
(b) Commitment tree based on
(a) The information S requires from
Merkle hash tree saves
A in the data aggregation phase:
bandwidth
• aggregation result f(x1…xn)
• the number of data samples n
Previous slide shows these are necessary
• a commitment of the data
samples hA.
32
Forces prover to commit to the sample values
Result verification – single
aggregator
hi,j=h(hi+1,2j||h i+1,2j+1)
h0,0
Sink S
q || A || f(x1,x2,...,xn ) || n || h A || MACAS
h1,0
A
q || ID(1) || x1 || MAC1S || MAC1A
1
2
...
n
x1
x2
...
xn
h1,1
h2,0
h2,1
h2,2
h2,3
x1
x2
x3
x4
(a)
(b)
A returns the following when interrogated by S:
M || MAC(KAS, M)
where M = q || ID(1) || x1 || MAC1S || ID(2) || x2 || MAC2S || h1,1
Prevents source nodes from lying
33
Result verification – multiaggregator
 Chan et al.’s hierarchical in-network aggregation
 Every sensor sends a message of the following format
to its parent:
query ID || value || complement || count || commitment || MAC
 Uses two primitives COMB and AGG
 AGG(msg1, msg2):
Let msg1 = q || v1 || c1 and msg2 = q || v2 || c2, then
AGG(msg1, msg2) = q || f(v1, v2) || c1+c2.
 COMB(msg1, msg2):
Let msg1 = q || v1 || c1 and msg2 = q || v2 || c2, then
COMB(msg1, msg2) = q || v1 || c1 || v2 || c2.
34
Aggregation phase [Chan
et al.]
Sink S
COMB(AGG(B2, H2), G1)
B2
C1
C
B
A
D1
DF
COMB(H2, G1)
E
G
I1
I
H2 = q || f(xI,xJ ) || 2 || h(q||f(xI,xJ)||2||I1||J1)
H
J1 = q || xJ || 1
J
 Aggregate only trees of the same size to create
balanced binary trees
 The advantage of creating only balanced binary trees
is that edge congestion (congestion on a link) is only
O(log2n), where n is the number of samples
35
Verification phase [Chan
et al.]
Sink S
COMB(AGG(B2, H2), G1)
B2
C1
C
B
A
D1
DF
COMB(H2, G1)
E
G
I1
I
H2 = q || f(xI,xJ ) || 2 || h(q||f(xI,xJ)||2||I1||J1)
H
J1 = q || xJ || 1
J
 S broadcasts COMB(AGG(B2, H2), G1) to the network, for example,
using μTESLA. Next, the following transmissions take place:

A  B: H2
A  E: COMB(B2, G1)
B  C: COMB(H2, D1)
B  D: COMB(H2, C1)
E  G: COMB(B2, G1)
G  H: B2
H  I: COMB(B2, J1)
H  J: COMB(B2, I1)
 A source node that successfully reconstructs the commitment will
send a confirmation message to the sink:
q||nodeID||OK MAC(K, q||nodeID||OK)
 Problem is instead of at the sink, the commitment is reconstructed
at the source nodes themselves – an attacker can forge negative36
confirmations
Result verification – SDAP
 Better than previous approach, because commitment is re-constructed
at the sink, not the source nodes
 We divide the sub-network into groups, we only need to check the
groups which look suspicious
 A sensor decides whether it would become a group leader by checking
whether h(q||nodeID) < Fg(c), where Fg(c) is a function that increases with
the data count c
 The role of a group leader is to set a boolean flag in a message to NAGG
to indicate the message needs only be forwarded, not aggregated
Sink S
MACGS
A
B
C
E
q || G || f(xH , f(xI, xJ)) || 3 || NAGG || MAC(KGS , q||G||f(xH , f(xI, xJ ))||3||NAGG ||MACHS )
D F
G
q || H || f(xI, xJ ) || 2 || YAGG || MAC(K HS, q||H||f(xI, xJ )||2||YAGG ||MACISMACJS)
H
q || I || xI || 1 || YAGG || MACIS
I
J
MACHS
q || J || xJ || 1 || YAGG || MAC(KJS, q||J||xJ||1||YAGG )
MACJS
37
SDAP’s aggregation phase
Sink S
MACGS
A
B
C
E
q || G || f(xH , f(xI, xJ)) || 3 || NAGG || MAC(KGS , q||G||f(xH , f(xI, xJ))||3||NAGG ||MACHS )
DF
G
q || H || f(xI, xJ ) || 2 || YAGG || MAC(K HS, q||H||f(xI, xJ)||2||YAGG ||MACISMACJS)
H
q || I || xI || 1 || YAGG || MACIS
I
J
MACHS
q || J || xJ || 1 || YAGG || MAC(KJS, q||J||xJ||1||YAGG )
MACJS
 S tests if h(q||leader’s nodeID) < Fg(c). If false, S
discards the group aggregate. Otherwise, S
proceeds with the next test.
 S tests if the group aggregate represents an
outlier
38
SDAP’s verification phase
 S  A: G || q || qa
 G  S: qa || G || xG || 3 || MACGS
MAC
A
H  S: qa || H || xH || 2GS || MACHS
q || G || f(xH , f(xI, xJ)) || 3 || NAGG || MAC(KGS , q||G||f(xH , f(xI, xJ))||3||NAGG ||MACHS )
J  S: qa || J || xJ || 1 || MACJS
B
E
|| YAGG || S:
MAC(K
||MACISMACJS)
C
DF
G q || H || f(xI, xJ ) ||I2
qa ||HS, Iq||H||f(x
|| xI I,||xJ)||2||Y
1 || AGG
MAC
IS
MACHS
H
q || I || xI || 1 || YAGG || MACIS
 S performs the following checks:
I
J q || J || xJ || 1 || YAGG || MAC(KJS, q||J||xJ||1||YAGG )
 xG is correctly
MACJSderived from f(xG, f(xJ, xI))
 MACGS is correctly reconstructed in the
following steps:
 MACIS = MAC(KIS, q || I || xI || 1)
 MACJS = MAC(KJS, q || J || xJ || 1)
 MACHS = MAC(KHS, q || H || f(xJ, xI) || 2 ||
MACIS  MACJS)
 MACGS = MAC(KGS, q || G || f(xG, f(xJ, xI))
|| 3 || MACHS)
Sink S
39
Progress so far…
4
1
2
3
40
Privacy homomorphism
(PH)
 First proposed by Rivest et al. in 1978 to process encrypted data
without decrypting the data first
 A function is (,)-homomorphic if
f(x)  f (y) = f (x  y)
where ‘’ is an operator in the range and ‘’ is an operator in the
domain.
 If f is an encryption function and the inverse function f-1 is the
corresponding decryption function, then f is a PH.
41
Types of PHs
 There are three main approaches to PHs in WSNs so
far:
 PHs that are based on polynomial rings, e.g.,
Domingo-Ferrer’s scheme
 PHs that are based on one-time pads
 homomorphic public-key cryptosystems
Insecure under known-plaintext attacks
Attacks involve only computation of gcd and
linear algebra [Wagner 03]
42
PHs based on one-time
One-time
pads
pad

Encryption:
n
C
n
 E(k , m )  ( m   k ) mod p
i
i 1

Decryption by sink:
n
i
i
i 1
n
i 1
n
 m mod p  C   k mod p
i
i
i 1

i
i 1
Drawbacks:
 Use of the addition operator in place of the XOR operator in the plaintext
space is unproven in terms of security
 Synchronization of keys causes scalability problem
m1 + m2+ k1 + k2
m1 + k1
m1+m2+m3+k1+ k2+k3
m1+m2+m3+m4+k1+ k2+k3+k4
m3 + k3
m2 + k2
m4 + k4
sink
43
Security of homomorphic
public-key cryptosystems
Security notions for
public-key cryptosystems
 PHs are different from conventional ciphers in the sense that the
highest attain-able security for PHs is semantic security under
non-adaptive chosen-ciphertext attacks (IND-CCA1)
 PHs are also by definition malleable, so they fail all the nonmalleability notions
 In practice, we only look for PHs that are semantically secure
against chosen-plaintext attacks (IND-CPA)
44
Candidate cryptosystems
 ElGamal on elliptic curves (EG-EC)
 Semantic security depends on the discrete
logarithm problem on elliptic curves
 (+,+)-homomorphic
 Okamoto-Uchiyama
 Semantic security depends on the
intractability of factoring p2q
 (,+)-homomorphic
45
(real-time)
Guideline [Mykletun et al. 06]
(intermediate nodes might
want to decrypt the intermediate
values)
46
Part One Conclusion
 Among the techniques introduced so far, voting,
result verification and PH all require a lot of
resources.
 Only resilient aggregation is the most practical.
 If all data are only aggregated once, then
RANBAR, or a simple resilient aggregation
function can be used.
 For multi-aggregation scenarios, quantiles
aggregation can be used at each aggregation
point to compress the data.
 Instead of PH, encrypted data are decrypted
and then aggregated and re-encrypted – no 47
true end-to-end confidentiality.
aggregate
aggregate
Part Two
Key management
aggregate
In Secure Data Aggregation, we secure one-way traffic.
generalized
48
In Key Management, we secure generic traffic.
Components
Protocol
verification
1
Key management
2
Key establishment
3
Key refreshment
4
Key revocation
49
Protocol verification
 Verification gives us indication and confidence
of security
 If we simulate unbounded sessions, verification
of secrecy and authentication is undecidable
 If we limit number of parallel sessions, we can
use constraint solving for verification
 Model: strand space model
 Tool: CoProVe implements the strand space
model using constraint solving (Prolog)
50
Strand space model
Protocol
Strand space model
Role: What a principal does in Strand: A sequence of events
the protocol
Complete run: A complete
iteration of the protocol
Bundle: A set of strands 
legitimate or otherwise 
hooked together where one
strand sends a message and
another receives that same
message, that represents a full
protocol exchange
Example
Initiator, responder, server
1. Initiator  Attacker: …
2. Attacker  Responder: …
3. Responder  Attacker: …
4. Attacker  Initiator: …
51
Node-to-node key
establishment
A wants to establish a secure channel with B via a
common trusted node S:
A  B: NA || A
B  S: NA || NB || A || B || MAC(KBS, NA || NB || A || B)
S  A: E(KAS, KAB) || MAC(KAS, NA || B || E(KAS, KAB))
S  B: E(KBS, KAB) || MAC(KBS, NB || A || E(KBS, KAB))
A  B: Ack || MAC(KAB, Ack)
52
Node-to-node key
establishment
NA || AAB, Ack)
Ack || MAC(K
53
Verification using CoProVe
Strand space model
send  …
recv  …
…
Role n:
Scenario:
Instantiate Role 1
…
Instantiate Role n
Instantiate Outcome
Bundle
Strands
Role 1:
send  …
recv  …
Outcome: e.g.,
attacker learns key
has_to_finish(Outcome)
Security is disproved if there exists a bundle that satisfies these
constraints
54
Verification using CoProVe
– the code itself
initiator(A, S, B, Na, Ns, Ka, Kb, Kab, responder(A, B, Nb, Ns, Kb, Kab,
Ack, [
Ack, [
recv([A, [S, B]]),
recv([A, Ns+Kb]),
send([Na, B]+Ka),
send([B, [Nb, [A, Ns]]]+Kb),
recv([Ns+Kb, [Kab, [Na, B]]]+Ka),
recv([Kab, [Nb, A]]+Kb),
send([A, Ns+Kb]),
send([Ack]+Kab)
recv([Ack]+Kab)
]).
]).
secrecy(N, [recv(N)]).
server(A, B, Na, Ns, Nb, Ka, Kb, Kab, scenario([[a, Init1], [b, Resp1], [s,
Serv1], [sec, Secr1]]) :[
initiator(a, s, B, na, Ns, ka, Kb, Kab,
recv([Na, B]+Ka),
ack, Init1),
send([Ns+Kb, [Kab, [Na, B]]]+Ka),
server(a, b, Na, ns, Nb, ka, kb, kab,
recv([B, [Nb, [A, Ns]]]+Kb),
Serv1),
responder(A, b, nb, Ns1, kb, Kab1,
send([Kab, [Nb, A]]+Kb)
ack, Resp1),
]).
secrecy(kab, Secr1).
has_to_finish([sec]).
55
Components
Protocol
verification
1
Key management
2
Key establishment
3
Key refreshment
4
Key revocation
56
Key establishment
 Definition: a process or protocol whereby
a shared secret key becomes available to
two or more parties, for subsequent
cryptographic use
 Types:Key establishment
A key agreement
Key transport
Key agreement
Key pre-distribution
protocol whereby
the resulting
established keys
are completely
determined a priori
by initial keying
material
57
Protocol design by
communication modes
 Global broadcasts:
 Authenticated broadcast using μTESLA
 Local broadcasts:
 Passive participation
 Unicast:
 Only consider neighbour-to-neighbour
 Multihop can be secured hop by hop
 Random key pre-distribution schemes
 LEAP+
 EBS
58
Global broadcast: μTESLA
 “Micro” version of the Timed, Efficient, Streaming,
Loss-tolerant Authentication Protocol Authenticated
broadcast
keys are generated in reverse order
Ki-1 = h(Ki)
K1
K2
K3
K4
……
Kn
keys are released in forward order
Time interval:
Message:
i
Mi || MAC(Ki, Mi)
i+1
...
i+δ
Mi+δ || Ki || MAC(Ki+δ, Mi+δ || Ki)
authentication succeeds if
(1) Ki generates MAC
(2) and there exists a past key Kj = Hi-j (K i)
59
μTESLA example (1)
(1) Generate one-way reverse key chain
on the base station
h()
K1
K2
K3
(3) Generate one-way reverse key chain
on the base station
K4
(2) Give K1 to everybody
M
K2
MAC(K3, …)
K1
K1
K1
K1
60
μTESLA example (2)
(4) K2 is genuine because h(K2) = K1 but
packet tagged with MAC(K3, M||K2) still
needs to be authenticated
(5) Base station later sends K3 that can
be used to authenticate message M
M2
M MAC(K3, …)
K2
M
MAC(K3, …)
K2
K3
MAC(K4, …)
Authentication steps:
(a) K3 is genuine because
K2 = h(K3)
(b) M is genuine because
K3 is genuine and K3
61
authenticates M
Local broadcast: Passive
participation
A is just transmitting
a similar data to I
have, so I shall not
transmit.
D
C
E
B
A
Passive participation: nodes B, C, D, E
suppress their transmissions when they
find A transmitting about the same data
To secure passive participation, A uses
a cluster key and a one-way key chain
to achieve encrypted and authenticated
62
local broadcast
Local broadcast: Passive
participation
D
C
B
A
 If only the key chain is used, the keys
in the key chain would have to be
broadcast in the clear, and in the
absence of time interval differentiation,
a cluster-outsider would be able to
forge messages using these keys
 If only the cluster key is used,
authentication of the sender cannot be
achieved
 But if used together, the cluster key
can be used to encrypt messages as
well as to hide the key chain keys from
cluster-outsiders; and at the same
time, the key chain keys can be used
for authentication
63
Securing unicast
 Random key pre-distribution schemes
 LEAP+
 EBS
64
Random key predistribution (RKP)
at random
‘Keying material’
at random
Pool
Able to establish session key?
P = pool size
K = key ring size
(4 in this example)
(1 in this example)
65
Random key predistribution (RKP)
 Different types:
Type 1
Type 2
Type 3
t
f ( x, y) 
a
i jx
i
yj
i , j 0
Symmetric key
[Eschenauer & Gligor 02]
Symmetric bivariate polynomial
[Liu et al. 05]
Part of a matrix
[Du et al. 05]
66
Symmetric-key-based RKP
I’ve got keys 1, 2, 3, 4
I’ve got keys 1, 5, 6, 7
1
1
2
5
3
6
4
7
OK, so our
session key can
be derived from
key 1
OK, so our
session key
can be derived
from key 1
Although not all neighbouring pairs of nodes can establish a session
key (aka pairwise key), the network will remain connected, with a
suitable choice of K and P.
K = key ring size
(4 in this example)
P = key pool size
(7 in this example)
67
Symmetric-key-based RKP
Pr{connectivity ≥ k} vs k
K = 4, P = 15, RMSE = 0.0427
Pr{connectivity ≥ k}
K = 4, P = 30, RMSE = 0.0436
Expected connectivity
Derived from results of random
68
geometric graphs [Law et al. 07]
Polynomial-based
RKP
I’ve got f1(), f2()
I’ve got f2(), f3()
Node 1
f1(1, y) = 6+7y+8y2
f2(1, y) = 10+12y+14y2
t
f ( x, y) 
a
i jx
i , j 0
i
yj
f1(x, y) = 1+2y+3y2+2x+xy+4xy2
+3x2+4x2y+x2y2
f2(x, y) = 2+3y+5y2+3x+2xy+7xy2
+5x2+7x2y+2x2y2
f3(x, y) = 3+4y+5y2+4x+3xy+6xy2
+5x2+6x2y+3x2y2
Pool
Node 2
OK, so our
session key can
be derived from
f2()
OK, so our
session key
can be derived
from
f2()
f2(2, y) = 28+35y+27y2
f3(2, y) = 31 + 34y + 29y2
In this example, t = 2, K = 2, P = 3
The pairwise key is f2(1,2) = f2(2,1) = 10 + 24 + 56 = 28 + 35 + 27 = 90
*In reality, the value must of course be as large as normal crypto keys
Storage requirement: K(t + 1) coefficients, where t is the threshold
69
Matrix-based
RKP
N = number of nodes = number of columns
Vandemonde-like
generator matrix
Random
symmetric
matrices
1
s

G  s2


 s t
D1
M1=(D1G)T
1
s2
(s 2 )2
1
s3
(s3 )2
( s 2 )t
( s 3 )t
D2
M2
...
1 
...
s N 
... ( s N ) 2 


N t 
... ( s ) 
this seed can be
used as an ID
D3
D4
M3
M4
70
Matrix-based
RKP
M1
M3
M2
I’ve got M1, M2
M4
Pool
I’ve got M2, M3
Node 1
M1(1)
M2(1)
Node 2
G(1)
OK, so our
session key can
be derived from
M2
OK, so our
session key
can be derived
from
M2
G(2)
M3(2)
M2(2)
Here’s G(1)
Here’s G(2)
Pairwise key = M2(1)G(2) = M2(2)G(1)
Storage requirement: K(t+1)+1 coefficients, where t is the threshold
71
Node-to-node key
establishment
RKP schemes only good for keying two neighbouring nodes
with common key(s); what about neighbours without any
common key? Use common trusted node
A wants to establish a secure channel with B via a common
trusted node S:
A  B: NA || A
B  S: NA || NB || A || B || MAC(KBS, NA || NB || A || B)
S  A: E(KAS, KAB) || MAC(KAS, NA || B || E(KAS, KAB))
S  B: E(KBS, KAB) || MAC(KBS, NB || A || E(KBS, KAB))
A  B: Ack || MAC(KAB, Ack)
72
LEAP+
 LEAP+ is a key pre-distribution scheme but not random
 Every node is pre-distributed with Kin
0
A sets timer
1
Hello, I’m A
2
Node B
node key KB = PRF(Kin, B)
Kin already deleted
I’m B
Node A
initial key Kin
3
A and B compute pairwise key = PRF(PRF(Kin, B), A)
KB
4
Timer fires, A deletes Kin
73
EBS (Exclusion Basis
System)
 P   6
      15 key combinations
 K   4
Nodes
Keys
Pro: Two nodes always share at least 2K-P keys.
Con: When a node is compromised, more than half of
the keys in the key pool are compromised.
74
Components
Protocol
verification
1
Key management
2
Key establishment
3
Key refreshment
4
Key revocation
75
Key refreshment
 Why? The more a key is used, the more it is open to
cryptanalytic attacks, birthday attacks etc.
Parallel re-keying:
 Lose the key K, then all past and future keys are
exposed
 Not suitable for WSNs
76
Key refreshment
Serial re-keying: preferable because of forward security
 Only need to store this: PRF (...PRF (K0 , 0)..., 0)
i 1 times
i -1 times
 Lose this, then all future keys are compromised
 But past keys are intact
77
Abdalla et al. 2000
 Without this scheme, birthday threshold =
O(2k/2)
 With this scheme, a session key can be
refreshed O(2k/3) times
 Each time, a session key has a birthday
threshold of O(2k/3)
 The final birthday threshold is O(2k/3)  O(2k/3)
= O(22k/3)
78
Components
Protocol
verification
1
Key management
2
Key establishment
3
Key refreshment
4
Key revocation
79
Which keys to revoke?
KSglobal
KSchain
Big picture:
KSglobal
KBcluster
KB
B
KCcluster
K
K
chain
Base station
S
chain
S
Compromised
node
KEcluster
A
KEchain
chain
C
KD cluster
KDchain
C
KSglobal
E
KSchain
D
 When A is compromised
 Global broadcast keys: B, C, D, E need to have their copies of
KSglobal replaced
 Local broadcast keys: B, C, D, E need to purge KAcluster and
KAchain; B needs to re-gen and re-distribute KBcluster and KBchain;
similarly for C, D, E
80
Strategy
Gateway
81
Re-keying unicast keys
KSglobal
Big picture:
KSchain
KB
KB
B
KCcluster
K
KSglobal
cluster
Base station
S
KSchain
chain
Compromised
node
KEcluster
A
KEchain
chain
C
KD cluster
KDchain
C
KSglobal
E
KSchain
D
 If using polynomial-based or matrix-based RKP or
LEAP+, do nothing
 If using symmetric key-based RKP, re-keying is
desirable but can be done without
 If using EBS, re-keying is a must
82
Re-keying local broadcast
keys
83
Re-keying global
broadcast keys
New global key is propagated from the base station in two
stages:
(1) The hash of the key is propagated
(2) Then the key itself
Over each hop, the key is protected by a cluster key and
a cluster key chain
84
Part Two Conclusion
 Securing local broadcasts is generally too expensive
for current generation of nodes
 The priority is to secure query broadcasts, data
convergecasts and neighbour-to-neighbour unicasts
This means a node should minimally store




a unique key shared with the base station
a μTESLA commitment distributed by the base station
a global key
a set of pairwise keys, each of which is shared with a different
neighbour
 Periodic key refreshment should be made a standard
practice
 global key is used most often
 Always verify protocols
85
Thank y’all
Dank u
Danke
Grazie
Mult'umesc
Dziekuje
Köszönöm
Tesekkurler
Shukran
धन्यवाद
谢谢
86