5. Is security on sensors possible at all?[1]Is security on sensors possible at all?[1]
Memory constraints:-
-memory is not enough to store even the variables of standard asymmetric
key crypto systems.
-standard implementations of symmetric key primitives (ciphers and hash
functions) need to be optimized in order to fit in the memory.
-available memory may increase in the future (price is still an issue).
-some asymmetric crypto systems may require less resources.
Processor:-
-4 MHz, 8 bit RISC processor, with 32 general purpose registers
-limited instruction set
• good support for bit- and byte-level I/O operations
• lack of arithmetic and logic operations
Battery power:-
-will remain a crucial limitation for some time
-communications consume much more energy than computation
-crypto algorithms and PROTOCOLS must be designed and optimized to
reduce energy consumption
6. System AssumptionsSystem Assumptions
Communication patterns
-Node to base station (e.g. sensor readings)
-Base station to node (e.g. specific requests)
-Base station to all nodes
Base Station
-Sufficient memory, power
-Shares secret key with each node
Node
-Limited resources, limited trust
A
B
D
E
F
G
C
Base
Station
7. Communication architecture[2,3]Communication architecture[2,3]
RF communications broadcast
– easy to eavesdrop messages
– easy to inject fake messages
– easy to delete messages (jamming)
– modification of messages on-the-fly is hard
– but: delete – modify - re-inject may work
Typical communication patterns:
– many-to-one (nodes to base station) (measurement)
– one-to-many (base station to all nodes) (control information)
Nodes can
– recognize packets addressed to them (addressing)
– handle broadcast messages
– forward packets toward the base station (using the routing
topology)
The base station can access individual nodes using source routing, if
needed
8. Trust setup[1]Trust setup[1]
The base station is trusted by all nodes
Sensor nodes are untrusted
– they are unattended
– they are not tamper resistant
– they can be captured and compromised
RF communication channels are untrusted
Initial keys
– each node has a unique key that it shares with the base station
– compromise of this key affects only a single sensor
Time synchronization
– upper bound on the node ‘s clock drift
9. Security for Sensor Networks[1]Security for Sensor Networks[1]
Data Authentication:-
– it is easy to inject fake packets into the network
– special requirements of broadcast authentication
• symmetric MAC cannot be used
• asymmetric digital signatures are not feasible
Data Confidentiality:-
– sensor readings might be sensitive, some control data (e.g. keys) must be kept
secret
– eavesdropping is easy.
Data Integrity:-integrity of sensor readings and control data is important
Data Freshness:-freshness of sensor readings is usually important and replay of
old packets is easy
– weak freshness
• provides partial message ordering, but no delay information
• useful for sensor readings
– strong freshness
• allows delay estimation
• required by time synchronization
12. Properties of SNEP[1]Properties of SNEP[1]
Semantic security
– same messages are encrypted differently each time due to the different
counter value
Data authentication and integrity by using MAC
Weak freshness and replay protection
– counter is part of the MAC
– it ensures message ordering
Low communication overhead
– counter is not sent, it is maintained locally by both parties
– using the block cipher in CTR mode results in a stream cipher �
Encrypted messages has the same length as plain messages
– MAC adds only 8 bytes per message
Reduced computational overhead
– MAC verification doesn’t need decryption
13. Key Generation /Setup[4]Key Generation /Setup[4]
Nodes and base station share a master key pre-deployment
Other keys are bootstrapped from the master key:
◦ Encryption key
◦ Message Authentication code key
◦ Random number generator key
Counter
RC5 Block
CipherKey Master KeyMAC
KeyEncryption
Keyrandom
14. Building blocks: SNEP[1]Building blocks: SNEP[1]
Sensor Network Encryption Protocol (SNEP):
A B : encKenc,C(data) | macKmac(C|encKenc,C(data))
where
– encKenc,C is encryption in CTR mode with key Kenc and counter C
– macKmac is CBC-MAC computation with key Kmac
– MAC is computed over the encrypted data and counter C
– MAC length is 64 bits
– Kenc and Kmac is derived from the master key K (shared by the node and the base station)
through a one way function:
Kenc = macK(1)
Kmac = macK(2)
15. Authentication, Confidentiality[1]Authentication, Confidentiality[1]
Without encryption can have only authentication
For encrypted messages, the counter is included in the MAC
Base station keeps current counter for every node
Node A
M, MAC(Kmac, M)
{M}<Kencr, CA>,
MAC(Kmac, CA|| {M}<Kencr, CA>)
Node B
16. SNEP with strong freshness[1]SNEP with strong freshness[1]
A B : NA, request
B A : encKenc,C(response) | macKmac(NA|C|encKenc,C(response))
where
– the request can use plain SNEP for confidentiality and
authentication
– NA is an unpredictable random number computed as
NA = macKrnd(S)
– after generating a random number, S is incremented by one
– Krnd is a key derived from the master key K (shared by the node
and the base station) through a one way function:
Krnd = macK(3)
and regenerated from time to time:
Krnd’ = macK (Krnd)
17. Strong Freshness[1]Strong Freshness[1]
• Nonce generated randomly
• Sender includes Nonce with request
• Responder include nonce in MAC, but not in reply
Node A
Request, NA
{Response}<Kencr, CB),
MAC(Kmac, NA || CB|| {Response}<encr, CB>)
Node B
18. Counter Exchange Protocol[1]Counter Exchange Protocol[1]
Bootstrapping counter values
Node A
CA
CB, MAC(Kmac, CA||CB)
Node B
To synchronize:
A →B : CA
B →A : CB, MAC(Kmac,CA || CB).
19. Code re-use in SNEP[2]Code re-use in SNEP[2]
Only encryption part of RC5 is implemented
This is used
– to encrypt and to decrypt (due to CTR mode) data
– to implement the MAC function
– to generate encryption and MAC keys from the master key
– to generate random numbers
20. Building block:Building block:
µµTESLA Authenticated BroadcastTESLA Authenticated Broadcast
Main idea: asymmetry through delayed disclosure of authentication keys
– base station computes a MAC with a key unknown to the sensors
– base station sends and sensors receive the message with the MAC
– later, the base station discloses the key used to compute the MAC
Assumptions:
– loose time synchronization between the base station and the sensors
– each sensor knows an upper bound on the maximum synchronization
error
– initial secret between the base station and each sensor to bootstrap the
whole mechanism
21. Key Setup[1]Key Setup[1]
Main idea: One-way key chains
K0 is initial commitment to chain
Base station gives K0 to all nodes
Kn Kn-1 K1 K0
X
…….
F(Kn) F(K1)F(K2)
22. Broadcast[1]Broadcast[1]
Divide time into intervals
Associate Ki with interval i
Messages sent in interval i use Ki in MAC
Ki is revealed at time i + δ
Nodes authenticate Ki and messages using Ki
K0 K1 K2 K3 …
0 1 2 3 4 time
δ
23. Broadcasting Authenticated Packets[1]Broadcasting Authenticated Packets[1]
In interval j, base station broadcasts Msg
Node verifies that key Kj has not been disclosed yet
Node stores Msg
Node A Base Station
Tnow, Ki, Ti, Tint, δ, MAC(Kmaster, Nonce | Tnow | …)
Nonce
Msg, MAC(Kj, Msg)
24. Node authenticating packets[1]Node authenticating packets[1]
After disclosure interval δ, base station broadcasts Kj
Node verifies that F(Kj) = Kj-1, or F(F(Kj)) = Kj-2, etc.
Node verifies MAC of Msg
Node delivers Msg
Node A Base Station
Tnow, Ki, Ti, Tint, δ, MAC(Kmaster, Nonce | Tnow | …)
Nonce
Msg, MAC(Kj, Msg)
Kj
δ
25. Perfect robustness to packet loss[1]Perfect robustness to packet loss[1]
K2 K3 K4 K5
tTime 2 Time 3 Time 4 Time 5
K1
P5
K3
P3
K1
P2
K0
P1
K0
Verify MACs
P4
K2
FF
Authenticate K3
26. µµTESLA PropertiesTESLA Properties
Asymmetry from delayed key disclosure[1]
Self-authenticating keys[1]
Requires loose time synchronization[3]
Low overhead (1 MAC)
- Communication (same as SNEP)
- Computation (~ 2 MAC computations)
Independent of number of receivers
28. Discussion: DrawbacksDiscussion: Drawbacks
The µTESLA protocol lacks scalability[1]
- require initial key commitment with each nodes, which is very
communication intensive
SPINS uses source routing, so vulnerable to traffic analysis[2,3]
29. Conclusion[1,3]Conclusion[1,3]
Strong security protocols affordable
- First broadcast authentication
Low security overhead
- Computation, memory, communication
Apply to future sensor networks
-Energy limitations persist
-Tendency to use minimal hardware
Base protocol for more sophisticated security services
30. ReferencesReferences
[1] Adrian Perrig, Robert Szewczyk, Victor Wen, David Culler, J. D.
Tygar.”SPINS: Security Protocols for Sensor Networks”
[2] International Journal of Advanced Research in Computer Science andSoftware
Engineering[Volume- 3, Issue-8, August- 2013] “Emerging Trends in
Cryptography”
[3] Pritam Gajkumar Shah Lecturer, Telecom Engineering Department RV
College of Engineering, Bangalore ” Network Security Protocols for Wireless
Sensor Networks-A Survey ”
[4] Ali Modirkhazeni, Norafida Ithnin, Mohammadjavad Abbasi” Secure
Hierarchal Routing Protocols in Wireless Sensor Networks; Security Survey
Analysis ”
Low overhead (1 MAC) Communication (same as SNEP) Computation (~ 2 MAC computations) Perfect robustness to packet loss Independent of number of receivers No digital signature required
