SPINS: Security Protocols for Sensor Networks .

1. SPINS: Security Protocols for Sensor Networks. Adrian Perrig, Robert Szewczyk, Victor Wen, David Culler, J. D. Tygar Department of Electrical Engineering and Computer Sciences University of California, Berkeley {perrig, szewczyk, vwen, culler, tygar}@cs.berkeley.edu Presented on 13 may 2002 by Kristen Nielsen kristen@diku.dk Please ask questions during the speak

2. Is security on sensors possible? • Limited working memory and power consumption rules out the majority of current security algorithms. • Memory is to scarce to hold variables of the algorithms. • Transmission overhead is often huge. (1KB) • CPU does not support multiplication on large numbers. (=> huge overhead)

3. Sensor network architecture Sensor nodes establish a routing forest with base stations at the roots of every tree.

4. Requirements for sensor network security • Data Confidentiality • Sensor data is encrypted • Key distribution • Secure channels between Nodes and Base stations are used to bootstrap other secure channels • Data Authentication • The receiver of a packet can verify that the data really was sent by the claimed sender • Data Integrity • Ensures the receiver that the received data is not altered

5. Requirements for sensor network security. Cont... • Data Freshness • Ensures the reciever that data is recent • Weak freshness • Ensures message ordering from sending party • Used for sensor readings • Strong freshness • Ensures total message ordering of a request / response pair • Used for time synchronization between peers • Allows for delay estimation

6. Trust Setup • Base stations are trusted • Base stations are the GW for the nodes to communicate • Nodes receives a Master Key on “Setup” • Nodes trust themselves and their sensors • Small drift on internal clock

7. Design guidelines • Symmetric cryptography • Due to limited resources. • A single Block cipher routine is used to construct all cryptographic primitives • Encryption (RC5) • Message Authentication Code (MAC) (Hash) • Random number generator • Common state is maintained between peers • Reduced communication overhead

8. SPINS is: • SNEP: Secure Network Encryption Protocol. • µTESLA: the “micro” version of the Timed, Efficient, Streaming, Loss-tolerant Authentication Protocol.

9. Counter Counter SNEP Characteristics Data MAC Data packet format • Message counters is kept in each node. Used as I.V. for cipher • Data confidentiality • Two-party data authentication • Data freshness • Data Integrity • Low transmission overhead. Message 1:1, MAC 8 bytes. (approx 20 %) • Semantic security ~ 30 bytes 8 Data path Base station Node

10. Message Authentication Code (MAC) • MAC is used to achieve two-party authenticity and data integrity • Encrypted message format E={D}<Kencr,C> • MAC format M=MAC(Kmac, C|E)D=Data, Kencr=Encryption key, C=Counter (Cipher initialization vector)E=Encrypted message. Keys are derived from the Master secret key.

11. MAC function (CBC-MAC) • E = RC5 cipher block • K = Key • Xn = data input • H3 = MAC code

12. SNEP {weak, strong} freshness. • Weak freshness is standard in both SNEP and µTESLA. Message sequence are verified. • Strong freshness is achieved by the following algorithm: (N=nonce, R=Request mesg.) • A  B: NA, RA • B  A: {RB}<Kencr,C>, MAC(Kmac, NA|C|{RB}<Kencr,C> ) If the MAC verifies correctly, A knows that B generated the response after receiving the request from A, due to the nonce.

13. µTESLA Authenticated Broadcast • Broadcast transmissions can be in either direction • Sender and Receiver must be loosely time synchronized. • Transmission time is divided into time intervals • A one-way key chain is computed, and used in the reverse order to authenticate packets during the broadcast stream. (like S/Key one time passwords) • Sender broadcasts messages with a MAC that is secret to the “world” at transmission. • Short thereafter the MAC code for authorizeing the packet is transmitted from the sender.

14. µTESLA Time intervals & Key disclosures Time interval:0 1 2 3 4 Key# Packet# • Message P1 and P2 is broadcast in time interval 1. Mac is computed with Key K1. Key K1 is only known to the sending node • Receiver stores the message in its buffer • At time interval 3 the key K1 is disclosed by the sender. • The node can check the key authenticity with F(), and if it validates, then it can use the key to authenticate message P1 and P2

15. µTESLA Peer node initialization • A receiving node need: • Loosely time synchronization. • Current time Ts • starting time of time interval i, duration of a time interval Tint • A key Ki from the key chain for time interval i • The disclosure delay  • This setup and synchronization is done with the strong freshness protocol A  B: NA B  A: Tx|K|Ti|Tint|, MAC(KAB,NA |Ts|Ki|Ti|Tint| ) A= New receiving node, B= Broadcast Node, N=nonce, KAB=Secret key between node A and B

16. µTESLA When a node is broadcasting • Nodes are severely memory limited • Nodes can not store the keys of the one-way keychain • Do not share a secret key with each receiver • Ekstra power consumption when disclosing keys. • 3 approaches to this • The node broadcasts through the base station • The node broadcasts directly. The base station holds the key-chain, and sends keys to the broadcasting node as needed. • The node broadcasts the data directly, and the base station broadcasts the disclosed key, and/or do the initial bootstrapping of new nodes.

17. Key setup • All keys in a node is derived from a single master secret key K, shared by the base station and the node. • Fk(x) = MAC(K,x)

18. Encryption/Decryption function Input Output • Good encryption by this circuit requires a new ctr value each time a message is encrypted. • Output = {Input}<K,ctr> • K = key, • ctr = Counter value, • E=RC5 Block cipher function

19. Evaluation • The platform sets huge demand for code reuse. • Only 1 cipher function does all crypto work. • (En/de-cryption, MAC, Random number generator, key-chain computation, Key generation) • Memory scarceness was the major limitation • RC5 was implemented as a macro (inline code) • Cryptographic performance is adequate for current generations of network sensors.

20. Evaluation Code in Bytes Platform: 8KB program flash 512 bytes RAM 512 bytes EEprom Instructions PerformanceMax 30 Byte messages: 20 msgs/secCPU idle time: 50% RAM usage

21. Evaluation (Energy costs) SNEP protocol statistics • Encryption processing costs: 2-4 % of total energy • Transmission costs: approx 96-98 % of total energy

22. Conclusion • The SPINS concept is demonstrated to work • The design is to a large extent generic, and can easily be reused in other sensor networks. • Due to the sole use of fast symmetric cryptography the design is applicable to a wide variety of uses. • The platform limitations influenced our design in a few places: • The choice of the RC5 algorithm. • Very intensive reuse of code. • Very little memory for storing µTESLA messages flowing into the nodes

23. The End ?-! (Spørgsmål)